unix(4) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨 페이지 이름
검색(S)

unix(4)

The  protocol  family  is a collection of protocols that provides
local (on-machine) interprocess communication through the  normal
mechanisms.   The  family  supports the and socket types and uses
file system pathnames for addressing.   addresses  are  variable-
length  file system pathnames of at most 104 characters.  The in‐
clude  file  defines   this   address:   struct   sockaddr_un   {
        u_char  sun_len;                      u_char  sun_family;
        char    sun_path[104]; }; Binding a name to a socket with
causes a socket file to be created in the file system.  This file
is removed when the socket is closed — must be used to remove the
file.  The length of address, required by and can  be  calculated
by the macro defined in The field must be terminated by a charac‐
ter  to  be used with but the terminating is part of the address.
The protocol family does not support broadcast addressing or  any
form  of  matching  on  incoming messages.  All addresses are ab‐
solute- or relative-pathnames of other sockets.  Normal file sys‐
tem access-control mechanisms are also applied  when  referencing
pathnames;  e.g.,  the destination of a or must be writable.  The
sockets support the communication of file descriptors and process
credentials through the use of the field in the argument  to  and
The  items  to be passed are described using a that is defined in
the include file To send file descriptors, the type of  the  mes‐
sage is and the data portion of the messages is an array of inte‐
gers  representing the file descriptors to be passed.  The number
of descriptors being passed is defined by the length field of the
message; the length field is the sum of the size  of  the  header
plus the size of the array of file descriptors.  The received de‐
scriptor  is  a of the sender's descriptor, as if it were created
via or depending on whether is passed in the  call.   Descriptors
that  are  awaiting delivery, or that are purposely not received,
are automatically closed  by  the  system  when  the  destination
socket  is  closed.   Credentials  of  the sending process can be
transmitted explicitly using a control message  of  type  with  a
data portion of type defined in as follows: struct cmsgcred {
  pid_t cmcred_pid;             /* PID of sending process */
  uid_t cmcred_uid;             /* real UID of sending process */
  uid_t cmcred_euid;            /*   effective   UID  of  sending
process */
  gid_t cmcred_gid;             /* real GID of sending process */
  short cmcred_ngroups;         /* number of groups */
  gid_t cmcred_groups[CMGROUP_MAX];     /*  groups  */   };   The
sender should pass a zeroed buffer which will be filled in by the
system.   The  group  list  is  truncated  to  at most GIDs.  The
process ID should not be looked up (such as via the  sysctl)  for
making security decisions.  The sending process could have exited
and its process ID already been reused for a new process.  domain
sockets  support a number of socket options which can be set with
and tested with This option may be enabled on or a socket.   This
option  provides a mechanism for the receiver to receive the cre‐
dentials of the process calling or as  a  control  message.   The
field  in the structure points to a buffer that contains a struc‐
ture followed by a variable length structure, defined in as  fol‐
lows: struct sockcred {
  uid_t sc_uid;         /* real user id */
  uid_t sc_euid;        /* effective user id */
  gid_t sc_gid;         /* real group id */
  gid_t sc_egid;        /* effective group id */
  int   sc_ngroups;     /* number of supplemental groups */
  gid_t sc_groups[1];   /*  variable length */ }; The current im‐
plementation truncates the group list to  at  most  groups.   The
macro  computes  the size of the structure for a specified number
of groups.  The fields have  the  following  values:  cmsg_len  =
CMSG_LEN(SOCKCREDSIZE(ngroups)) cmsg_level = SOL_SOCKET cmsg_type
=  SCM_CREDS  On  and  sockets credentials are passed only on the
first read from a socket, then the system clears  the  option  on
the socket.  This option and the above explicit both use the same
value  but  incompatible control messages.  If this option is en‐
abled and the sender attached a control message with a it will be
discarded and a will be included.  Many setuid programs will data
at least partially controlled by the invoker, such as error  mes‐
sages.   Therefore,  a  message accompanied by a particular value
should not be trusted as being from that user.  Used  with  sock‐
ets,  this  option  causes  the  function to block until has been
called on the listening socket.  Requested via on  a  socket  re‐
turns  credentials  of the remote side.  These will arrive in the
form of a filled in structure, defined in as follows: struct  xu‐
cred {
  u_int cr_version;             /* structure layout version */
  uid_t cr_uid;                 /* effective user id */
  short cr_ngroups;             /* number of groups */
  gid_t cr_groups[XU_NGROUPS];  /* groups */ }; The fields should
be  checked  against  define.   The  credentials presented to the
server (the caller) are those of the client when  it  called  the
credentials presented to the client (the caller) are those of the
server when it called This mechanism is reliable; there is no way
for  either  party  to influence the credentials presented to its
peer except by calling the appropriate system call (e.g., or  un‐
der  different  effective  credentials.   To reliably obtain peer
credentials on a socket refer to the socket option.











































맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3