focal (7) unix.7.gz

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)