Was macht die Berechtigung x (Ausführen) für Unix-Sockets?

Nach meiner Erfahrung kann ein nicht privilegierter Benutzer nicht auf einen Unix-Socket zugreifen, den er nicht besitzt, ohne dass das x-Bit gesetzt ist. Was macht dieses Bit genau? Vielen Dank

linux permissions unix-sockets

— Владимир Тюхтин
quelle

Ist es die Berechtigung für die Sockets oder für das Verzeichnis?

— Rui F Ribeiro

An einer Steckdose. Das Verzeichnis hat den Modus 0755, sodass der Benutzer den Inhalt beobachten kann. Socket hat den Modus 0644, daher sollte der logische Benutzer (der zu "anderen" gehört, weil er keinen Socket besitzt, der zu einem Socket gehört, der eine Gruppe besitzt) in der Lage sein, in den Socket zu schreiben. Der Benutzer erhält jedoch die Nachricht zum Verweigern der Berechtigung, es sei denn, der Modus 0777 wird auf den Socket angewendet.

— Владимир Тюхтин

@ ВладимирТюхтин 0644bedeutet nur Leseberechtigung für die Gruppenmitglieder und "andere", sodass nur der Eigentümer auf den Socket zugreifen kann (da die Schreibberechtigung ihn steuert). 0666oder nur 0222weil keine Leseberechtigung erforderlich ist, würde dies ausreichen, um allen Zugriff zu gewähren. Aber anstatt jedem Berechtigungen zu erteilen, würde ich versuchen, Gruppen zu verwenden, um den Zugriff zu ermöglichen.

— Ilkkachu

Nichts, wie ich sehen kann.

Der Linux - man - Seite Unix (7) sagt , dass die Berechtigungen des Verzeichnisses eine Buchse enthält , gelten in der Regel (dh Sie müssen +xauf /fooeine Verbindung herstellen /foo/sock, und +wauf /fooerstellen /foo/sock) , und dass Schreibberechtigung Kontrollen an die Steckdose anschließen selbst:

Unter Linux erfordert die Verbindung zu einem Stream-Socket-Objekt eine Schreibberechtigung für diesen Socket. Das Senden eines Datagramms an einen Datagramm-Socket erfordert ebenfalls eine Schreibberechtigung für diesen Socket.

Anscheinend verhalten sich einige andere Systeme anders:

POSIX gibt keine Aussage über die Auswirkung der Berechtigungen auf eine Socket-Datei ab, und auf einigen Systemen (z. B. älteren BSDs) werden die Socket-Berechtigungen ignoriert. Tragbare Programme sollten sich aus Sicherheitsgründen nicht auf diese Funktion verlassen.

unix(4)on FreeBSD beschreibt ähnliche Anforderungen. In der Linux-Manpage wurde nicht angegeben, ob der Socket-Zugriff auf einigen Systemen auch die Verzeichnisberechtigungen ignoriert .

Das Entfernen des xBits aus dem Socket scheint einen anderen Fehler beim Ausführen des Sockets zu verursachen, aber das ist kein großer praktischer Unterschied:

$ ls -l test.sock
srwxr-xr-x 1 user user 0 Jun 28 16:24 test.sock=
$ nc -U ./test.sock
Hello
$ ./test.sock
bash: ./test.sock: No such device or address
$ chmod a-x test.sock
$ nc -U ./test.sock
Hello
$ ./test.sock
bash: ./test.sock: Permission denied

(Ich habe auch getestet, dass tatsächlich nur das wBit für den Zugriff auf den Socket unter Debians Linux 4.9.0 von Bedeutung zu sein scheint.)

Vielleicht hatten die Sockets, die Sie meinten, alle Berechtigungsbits vom Benutzer entfernt, oder Sie meinten das xBit im Verzeichnis?

— ilkkachu
quelle