Por que o comprimento do caminho do soquete é limitado a cem caracteres?

Question

Em nomes de caminhos de sistemas Unix, geralmente não há praticamente nenhuma limitação de tamanho (bem, 4096 caracteres no Linux) ... exceto para caminhos de arquivos de soquete que são limitados a around 100 caracteres (107 caracteres no Linux ).

• Primeira pergunta: por que uma limitação tão baixa?

Eu verifiquei que parece possível contornar essa limitação alterando o diretório de trabalho atual e criando em vários diretórios vários arquivos de soquete usando o mesmo caminho ./myfile.sock : os aplicativos cliente parecem se conectar corretamente ao servidor esperado processa mesmo que lsof mostre todos eles ouvindo no mesmo caminho de arquivo de soquete.

• Esta solução é confiável ou tive sorte?
• Esse comportamento é específico para o Linux ou esta solução alternativa também pode ser aplicada a outros Unixes?

Answer 1

Compatibilidade com outras plataformas ou compatibilidade com materiais antigos para evitar excessos ao usar snprintf() e strncpy() .

Michael Kerrisk explica no seu livro no página 1165 - Capítulo 57, Sockets: Domínio Unix:

SUSv3 doesn’t specify the size of the sun_path field. Early BSD implementations used 108 and 104 bytes, and one contemporary implementation (HP-UX 11) uses 92 bytes. Portable applications should code to this lower value, and use snprintf() or strncpy() to avoid buffer overruns when writing into this field.

Os caras do Docker até tiraram sarro, porque alguns soquetes tinham 110 caracteres:

• lol 108 caracteres ETOOMANY

É por isso que o LINUX usa um soquete de 108 caracteres. Isso poderia ser mudado? Claro. E essa é a razão pela qual, em primeiro lugar, essa limitação foi criada em sistemas operacionais mais antigos:

• Por que o comprimento máximo do caminho é permitido para soquetes unix no linux 108?

Citando a resposta:

It was to match the space available in a handy kernel data structure.

Quoting "The Design and Implementation of the 4.4BSD Operating System" by McKusick et. al. (page 369):

The memory management facilities revolve around a data structure called an mbuf. Mbufs, or memory buffers, are 128 bytes long, with 100 or 108 bytes of this space reserved for data storage.

Outros sistemas operacionais (soquetes de domínio unix):

• OpenBSD : 104 caracteres
• FreeBSD : 104 caracteres
• Mac OS X 10.9 : 104 caracteres

Answer 2

Em relação ao motivo, nwildner já escreveu uma excelente resposta .

Aqui, vou me concentrar apenas no uso do caminho relativo e do modo como.

Internamente, embora o arquivo de soquete também possa ser procurado pelo nome (eu acho), eles geralmente são procurados pelo inode. No Linux, esta pesquisa é assegurada pela função unix_find_socket_byinode() definida em net / unix / af_unix.c .

Isso pode ser facilmente verificado da seguinte forma:

• Crie dois diretórios A / e B / .
• Sob cada diretório, faça um processo escutar nos arquivos de soquete com o mesmo nome. Com socat você usaria um comando como:

$ socat UNIX-LISTEN:./my.sock -

• Troque agora os arquivos de soquete movendo A / my.sock para B / e vice-versa.
A partir de agora, se o aplicativo cliente se conectar a A / my.sock , ele entrará em contato com o servidor B e se ele se conectar a B / my. sock ele entrará em contato com o servidor A (note que quando a comunicação termina, o processo do servidor pode legitimamente apagar o que ele pensa ser seu próprio arquivo de soquete).

Eu verifiquei este comportamento em um punhado de sistemas Unix (Linux Debian, FreeBSD e OpenIndiana para obter alguma diversidade), então este comportamento parece ser pelo menos difundido, se não padrão.

Caminhos absolutos geralmente são usados como uma convenção entre o cliente e os processos do servidor, já que o processo do cliente pode não saber como estabelecer a comunicação inicial com o servidor.

No entanto, se essa comunicação inicial não for um problema, parece seguro usar caminhos relativos para a criação de arquivos de soquete, permitindo evitar problemas de comprimento de caminho quando o local do arquivo de soquete não é diretamente controlado pelo processo do servidor. >