Provided by: manpages-pt_20040726-4_all bug

NOME

       unix,  PF_UNIX,  AF_UNIX, PF_LOCAL, AF_LOCAL - Sockets para comunicação
       local interprocessos.

SINOPSE

       #include <sys/socket.h>
       #include <sys/un.h>

       unix_socket = socket(PF_UNIX, type, 0);
       error = socketpair(PF_UNIX, type, 0, int *sv);

DESCRIÇÃO

       A família de sockets PF_UNIX (também conhecida como PF_LOCAL ) é  usada
       para  comunicação  eficiente  entre processos na mesma máquina. Sockets
       Unix podem ser anônimos (criados pelo socketpair(2)) ou associados  com
       um  arquivo  do  tipo  do  socket.  O Linux também suporta um espaço de
       nomes abstrato, que é independente do sistema de arquivos.

       Tipos válidos são SOCK_STREAM para um  socket  orientado  a  stream,  e
       SOCK_DGRAM para um socket orientado a datagrama que preserva os limites
       das mensagens.  Os sockets Unix também são confiáveis e  não  reordenam
       os datagramas.

       Os   sockets   Unix  suportam  a  passagem  para  outros  processos  de
       descritores  de  arquivos  ou  credenciais  de  processos,  como  dados
       ancilares para datagramas.

FORMATO DE ENDEREÇO

       Um  endereço  Unix  é  definido  como  um nome de arquivo no sistema de
       arquivos ou como uma string única  no  espaço  de  nomes  abstrato.  Os
       sockets  criados  pelo  socketpair(2)  são  anônimos.  Para sockets não
       anônimos, o endereço-alvo pode  ser  setado  usando-se  connect(2).   O
       endereço  local  pode ser setado usando-se bind(2).  Quando um socket é
       conectado e ainda não tem um endereço local,  um  endereço  único  será
       gerado automaticamente no espaço de nomes abstrato.

              #define UNIX_PATH_MAX    108

              struct sockaddr_un {
                  sa_family_t  sun_family;              /* AF_UNIX */
                  char         sun_path[UNIX_PATH_MAX]; /* caminho de diretório */
              };

       sun_family  sempre  contém  AF_UNIX.   sun_path  contém  o  caminho  de
       diretório, terminado em zero, do socket no  sistema  de  arquivos.   Se
       sun_path  começa  com  um  byte  zero, ele se refere ao espaço de nomes
       abstrato mantido pelo módulo do protocolo Unix.  O endereço  do  socket
       neste espaço de nomes é dado pelo restante dos bytes em sun_path.  Note
       que os nomes no espaço de nomes abstrato não são terminados em zero.

OPÇÕES DE SOCKET

       Por razões históricas, essas opções de socket são especificadas com  um
       tipo  SOL_SOCKET  mesmo  sendo  específicos do PF_UNIX.  Eles podem ser
       selecionados com setsockopt(2) e lidos com getsockopt(2) especificando-
       se SOL_SOCKET como a família de socket.

       SO_PASSCRED  habilita o recebimento das credenciais da mensagem ancilar
       de processo de envio. Quando essa opção é setada e o socket  ainda  não
       está  conectado, um nome único será gerado automaticamente no espaço de
       nomes abstrato.  Espera um flag booleano inteiro.

MENSAGENS ANCILARES

       Por  razões  históricas,  esses  tipos  de  mensagens   ancilares   são
       especificados  com  um  tipo  SOL_SOCKET  mesmo  sendo  específicos  do
       PF_UNIX.  Para enviá-los, setar o campo cmsg_level da estrutura cmsghdr
       com  SOL_SOCKET, e o campo cmsg_type com o tipo. Para mais informações,
       veja cmsg(3).

       SCM_RIGHTS
              Envia ou recebe um conjunto de descritores de arquivo  de  outro
              processo.   A  porção de dados contém uma matriz de inteiros com
              os descritores de arquivos.  Os descritores de arquivo  passados
              se comportam como se tivessem sido criados com dup(2).

       SCM_CREDENTIALS
              Envia  ou  recebe  credenciais do unix. Isto pode ser usado para
              autenticação.  As credenciais são  passadas  como  uma  mensagem
              ancilar de struct ucred

              struct ucred {
                  pid_t  pid;  /* "process id" do processo de envio */
                  uid_t  uid;  /* "user id" do processo de envio */
                  gid_t  gid;  /* "group id" do processo de envio */
              };

       As  credenciais que o remetente especifica são verificadas pelo kernel.
       Um processo com id de usuário efetivo igual  a  0  tem  permissão  para
       especificar valores que não casam com o seu próprio valor.  O remetente
       precisa especificar seu próprio id de processo (a menos que  ele  tenha
       CAP_SYS_ADMIN),  seu id de usuário, id de usuário efetivo ou setar o id
       de usuário (a menos que ele tenha CAP_SETUID), e seu id de grupo, id de
       grupo  efetivo  ou  setar  o  id  do  grupo  (a  menos  que  ele  tenha
       CAP_SETGID).  Para  receber  uma  mensagem  de  struct  ucred  a  opção
       SO_PASSCRED precisa estar habilitada no socket.

VERSÕES

       SCM_CREDENTIALS  e  o espaço de nomes abstrato foram introduzidos com o
       Linux 2.2 e não deve ser usados em programas portáveis.

NOTAS

       Na implementação Linux, os sockets  que  são  visíveis  no  sistema  de
       arquivos  respeitam  as  permissões  do diretório onde eles estão. Seus
       proprietários, grupo e permissões podem ser alterados.  A criação de um
       novo  socket  falhará  se  o  processo não tiver permissão de escrita e
       busca (execução) no diretório no qual o socket é criado.  A conexão com
       o   objeto   do  socket  requer  permissão  de  leitura/escrita.   Este
       comportamento difere de muitos sistemas derivados do BSD,  que  ignoram
       permissões  para  sockets  Unix.  Programas portáveis não devem confiar
       nessa implementação, por segurança.

       Ligar-se a um socket com um nome de arquivo cria um socket  no  sistema
       de  arquivos  que precisa ser deletado por que chama quando ele não for
       mais necessário (usando-se unlink(2)).  Aplica-se  a  semântica  "fecha
       para  trás"  normal  do  Unix;  o  socket pode ser desligado a qualquer
       momento, e será finalmente removido do sistema  de  arquivos  quando  a
       última referência a ele for encerrada.

       Para  enviar  descritores  de  arquivos  ou  credenciais,  você precisa
       enviar/ler pelo menos um byte.

ERROS

       ENOMEM Sem memória.

       ECONNREFUSED
              connect(2) foi chamado com um objeto  de  socket  que  não  está
              escutando.  Isto  pode  acontecer  quando  um  socket remoto não
              existe, ou o nome de arquivo não é um socket.

       EINVAL Um argumento inválido foi passado. Uma causa comum é a perda  de
              configuração  do  AF_UNIX no campo sun_type do endereço passado,
              ou o socket está em um estado inválido para a operação aplicada.

       EOPNOTSUPP
              Uma  operação de stream foi chamada em um socket não orientado a
              stream, ou tentou usar uma opção de dados fora de banda.

       EPROTONOSUPPORT
              O protocolo passado não é PF_UNIX.

       ESOCKTNOSUPPORT
              Tipo de socket desconhecido.

       EPROTOTYPE
              O socket remoto não encontra o tipo de socket local  (SOCK_DGRAM
              vs. SOCK_STREAM).

       EADDRINUSE
              O  endereço local selecionado já foi pego, ou o objeto de socket
              do sistema de arquivo já existe.

       EISCONN
              connect(2)  foi  chamado  em  um  socket  já  conectado,  ou  um
              endereço-alvo foi especificado em um socket conectado.

       ENOTCONN
              A  operação  de socket precisa de um endereço-alvo, mas o socket
              não está conectado.

       ECONNRESET
              O socket remoto foi encerrado inesperadamente.

       EPIPE  O socket remoto  foi  encerrado  em  um  socket  de  stream.  Se
              habilitado,  um  SIGPIPE é enviado também. Isto pode ser evitado
              pela passagem da  flag  MSG_NOSIGNAL  para  sendmsg(2)  ou  para
              recvmsg(2).

       EFAULT O endereço de memória do usuário não era válida.

       EPERM  O remetente passou credenciais inválidas na struct ucred.

       Outros  erros podem ser gerados pela camada genérica de sockets ou pelo
       sistema de arquivos, enquanto geram um objeto de socket do  sistema  de
       arquivos.   Veja   as   páginas  de  manual  apropriadas  para  maiores
       informações.

VEJA TAMBÉM

       recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), socket(7)

CRÉDITOS

       Esta página de manual foi escrita por Andi Kleen.

TRADUZIDO POR LDP-BR em 21/08/2000.

       Rubens  de  Jesus  Nogueira  <darkseid99@usa.net>  (tradução)   Xxxxxxx
       Xxxxxxxxx Xxxxxxxx <xxxxxxxxx@xxxxxxx> (revisão)