Почему длина пути сокета ограничена сотней символов?

В Unix-системах имена путей обычно практически не имеют ограничений по длине (ну, 4096 символов в Linux) ... за исключением путей к файлам сокетов, которые ограничены примерно 100 символами (107 символов в Linux ).

• Первый вопрос: почему такие низкие ограничения?

Я проверил, что кажется возможным обойти это ограничение, изменив текущий рабочий каталог и создав в разных каталогах несколько файлов сокетов, использующих один и тот же путь ./myfile.sock: клиентские приложения, похоже, правильно подключаются к ожидаемым процессам сервера, хотя и lsofотображают все из них прослушивание по одному и тому же пути к файлу сокета.

• Этот обходной путь надежен или мне просто повезло?
• Это поведение специфично для Linux или этот обходной путь применим также и к другим Unix?

Совместимость с другими платформами или совместимость со старыми компонентами, чтобы избежать переполнения при использовании snprintf()и strncpy().

Майкл Керриск объясняет в своей книге на странице 1165 - Глава 57, Сокеты: домен Unix:

SUSv3 не указывает размер поля sun_path. Ранние реализации BSD использовали 108 и 104 байта, а одна современная реализация (HP-UX 11) использует 92 байта. Переносимые приложения должны кодировать это более низкое значение и использовать snprintf () или strncpy (), чтобы избежать переполнения буфера при записи в это поле.

Парни из Docker даже посмеялись над этим, потому что некоторые сокеты имели длину 110 символов:

• LOL 108 символов ETOOMANY

Вот почему LINUX использует гнездо с 108 символами. Можно ли это изменить? Конечно. И это причина, по которой в первую очередь это ограничение было создано на старых операционных системах:

• Почему максимальная длина пути разрешена для сокетов unix в linux 108?

Цитирую ответ:

Он должен был соответствовать пространству, доступному в удобной структуре данных ядра.

Цитата "Разработка и внедрение операционной системы 4.4BSD" McKusick et. и др. (страница 369):

Средства управления памятью вращаются вокруг структуры данных, называемой mbuf. Mbufs, или буферы памяти, имеют длину 128 байтов, при этом 100 или 108 байтов этого пространства зарезервированы для хранения данных.

Другие ОС (доменные сокеты Unix):

• OpenBSD : 104 символа
• FreeBSD : 104 символа
• Mac OS X 10.9 : 104 символа

Что касается того, почему, nwildner уже написал отличный ответ .

Здесь я остановлюсь только на том, как и как использовать относительный путь.

Внутренне, хотя файл сокета также можно искать по имени (я полагаю), он обычно ищется по индоду. В Linux этот поиск обеспечивается функцией, unix_find_socket_byinode()определенной в net / unix / af_unix.c .

Это можно легко проверить следующим образом:

• Создайте две директории A / и B / .
• В каждом каталоге заставьте процесс прослушивать файлы сокетов с одинаковыми именами. С socatвами будет использовать команду, такую ​​как:

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

• Теперь обменяйтесь файлами сокетов, переместив A / my.sock в B / и наоборот.
• С этого момента , если клиентское приложение подключается к A / my.sock, оно связывается с сервером B , а если оно подключается к B / my.sock, оно связывается с сервером A (обратите внимание, что, когда связь заканчивается, процесс сервера может законно удалить то, что он считает своим собственным файлом сокета).

Я проверил это поведение в нескольких системах Unix (Linux Debian, FreeBSD и OpenIndiana, чтобы получить некоторое разнообразие), поэтому такое поведение, по-видимому, является по меньшей мере широко распространенным, если не стандартным.

Абсолютные пути обычно используются в качестве соглашения между клиентским и серверным процессами, поскольку клиентский процесс может иначе не знать, как установить начальную связь с сервером.

Однако, если это первоначальное взаимодействие не является проблемой, представляется безопасным использование относительных путей для создания файлов сокетов, что позволяет избежать проблем с длиной пути, когда местоположение файла сокета напрямую не контролируется процессом сервера.