Provided by: manpages-pt_20040726-5_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)

Página do Manual Linux                             07/05/1999                                            UNIX(7)