Dlaczego długość ścieżki gniazda jest ograniczona do stu znaków?

W systemach uniksowych nazwy ścieżek zwykle nie mają praktycznie żadnego ograniczenia długości (cóż, 4096 znaków w systemie Linux) ... z wyjątkiem ścieżek plików gniazd, które są ograniczone do około 100 znaków (107 znaków w systemie Linux ).

• Pierwsze pytanie: dlaczego tak niskie ograniczenie?

Sprawdziłem, czy można obejść to ograniczenie, zmieniając bieżący katalog roboczy i tworząc w różnych katalogach kilka plików gniazd przy użyciu tej samej ścieżki ./myfile.sock: aplikacje klienckie wydają się poprawnie łączyć z oczekiwanymi procesami serwera, chociaż lsofpokazuje wszystkie z nich nasłuchuje na tej samej ścieżce pliku gniazda.

• Czy to obejście jest niezawodne, czy miałem szczęście?
• Czy to zachowanie jest specyficzne dla Linuksa, czy może to obejście dotyczy również innych Uniksów?

Zgodność z innymi platformami lub kompatybilność ze starszymi urządzeniami, aby uniknąć przekroczeń podczas używania snprintf()i strncpy().

Michael Kerrisk wyjaśnia w swojej książce na stronie 1165 - Rozdział 57, Gniazda: Domena Unix:

SUSv3 nie określa wielkości pola sun_path. Wczesne implementacje BSD wykorzystywały 108 i 104 bajty, a jedna współczesna implementacja (HP-UX 11) wykorzystuje 92 bajty. Aplikacje przenośne powinny kodować do tej niższej wartości i używać snprintf () lub strncpy (), aby uniknąć przepełnienia bufora podczas pisania w tym polu.

Ludzie z dokerów nawet się z tego wyśmiewali, ponieważ niektóre gniazda miały długość 110 znaków:

• lol 108 znaków ETOOMANY

Dlatego LINUX używa gniazda 108 znaków. Czy można to zmienić? Oczywiście. I właśnie dlatego ograniczenie to zostało utworzone w starszych systemach operacyjnych:

• Dlaczego dozwolona jest maksymalna długość ścieżki dla gniazd unixowych na Linuksie 108?

Cytując odpowiedź:

Miał pasować do przestrzeni dostępnej w poręcznej strukturze danych jądra.

Cytując „Projekt i wdrożenie systemu operacyjnego 4.4BSD” McKusick i in. glin. (strona 369):

Funkcje zarządzania pamięcią obracają się wokół struktury danych zwanej mbuf. Mbufy lub bufory pamięci mają długość 128 bajtów, przy czym 100 lub 108 bajtów tego miejsca jest zarezerwowanych do przechowywania danych.

Inne systemy operacyjne (gniazda domeny unix):

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

Jeśli chodzi o to, nwildner napisał już doskonałą odpowiedź .

Tutaj skupię się na tym, jak i względne użycie ścieżki.

Wewnętrznie, chociaż plik gniazda można również wyszukać według nazwy (tak sądzę), zwykle są one wyszukiwane według i-węzła. W Linuksie to wyszukiwanie zapewnia funkcja unix_find_socket_byinode()zdefiniowana w net / unix / af_unix.c .

Można to łatwo sprawdzić w następujący sposób:

• Utwórz dwa katalogi A / i B / .
• W każdym katalogu uruchom proces nasłuchiwania plików gniazd o tej samej nazwie. Z socatużyłbyś polecenia takiego jak:

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

• Teraz wymień pliki gniazd, przenosząc A / my.sock do B / i odwrotnie.
• Odtąd, jeśli aplikacja kliencka połączy się z A / my.sock , skontaktuje się z serwerem B , a jeśli połączy się z B / my.sock , skontaktuje się z serwerem A (pamiętaj jednak, że po zakończeniu komunikacji proces serwera może zgodnie z prawem usuń to, co uważa za własny plik gniazda).

Sprawdziłem to zachowanie na kilku systemach uniksowych (Linux Debian, FreeBSD i OpenIndiana, aby uzyskać pewną różnorodność), więc to zachowanie wydaje się być co najmniej szeroko rozpowszechnione, jeśli nie standardowe.

Ścieżki bezwzględne są zwykle używane jako konwencja między procesami klienta i serwera, ponieważ proces klienta może nie wiedzieć, jak ustanowić początkową komunikację z serwerem.

Jeśli jednak ta początkowa komunikacja nie stanowi problemu, wydaje się, że bezpieczne jest używanie ścieżek względnych do tworzenia plików gniazd, co pozwala uniknąć problemów z długością ścieżek, gdy lokalizacja pliku gniazda nie jest bezpośrednio kontrolowana przez proces serwera.