Wie gelten Dateiberechtigungen für Symlinks?

Question

Nehmen wir an, Sie haben diese Struktur:

+ directory -- file1 -- file2 -- file3 -> /tmp/file3

file3 ist ein Link zu einem anderen file3 an einer anderen Stelle im System.

Nehmen wir nun an, ich chmod 777e das Verzeichnis und den gesamten Inhalt darin. Erhält mein file3 in /tmp diese Berechtigungen? Nehmen wir auch an, wir haben die gleiche Situation, aber umgekehrt.

/tmp/file3 -> /directory/file3

Wie wirkt sich die Verknüpfung aus, wenn ich die Berechtigungen für die verknüpfte Datei anwende?

peth · Accepted Answer

Dies hängt davon ab, wie Sie chmod aufrufen und auf welcher Plattform Sie ausgeführt werden.

Auf einem Linux-System sagt man chmod beispielsweise Folgendes:

chmod ändert niemals die Berechtigungen von symbolischen Links. Der Systemaufruf chmod kann ihre Berechtigungen nicht ändern. Dies ist kein Problem, da die Berechtigungen von symbolischen Links niemals verwendet werden. Für jeden in der Befehlszeile aufgeführten symbolischen Link ändert chmod jedoch die Berechtigungen der Datei, auf die verwiesen wird. Im Gegensatz dazu ignoriert chmod symbolische Links, die bei rekursiven Verzeichnisdurchläufen auftreten.

Auf einem Mac kann chmod jedoch verwendet werden, um die Berechtigungen eines symbolischen Links mit folgenden Optionen zu ändern (von man chmod):

-h Wenn die Datei eine symbolische Verknüpfung ist, ändern Sie den Modus der Verknüpfung selbst und nicht die Datei, auf die die Verknüpfung verweist.

Nehmen wir zum Beispiel an, dass Sie sich für den Rest dieser Antwort auf einem Linux-Computer befinden.

Wenn Sie im ersten Fall chmod -R 777 directory ausführen, um die Berechtigungen rekursiv zu ändern, ist das Linkziel nicht betroffen. Wenn Sie chmod 777 directory/* ausführen, ist dies jedoch der Fall.

Wenn Sie die Berechtigungen für das Linkziel direkt ändern, werden diese Berechtigungen durchgesetzt (da als Manpage und baraboom die tatsächlichen Linkberechtigungen für nichts verwendet werden).

Testprotokoll zur Veranschaulichung:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3 $ ls -l dir/* /tmp/file3 -rw-r--r-- 1 user group 0 2011-06-27 22:02 /tmp/file3 -rw-r--r-- 1 user group 0 2011-06-27 22:02 dir/file1 -rw-r--r-- 1 user group 0 2011-06-27 22:02 dir/file2 lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3 $ chmod -R 777 dir && ls -l dir/* /tmp/file3 -rw-r--r-- 1 user group 0 2011-06-27 22:02 /tmp/file3 -rwxrwxrwx 1 user group 0 2011-06-27 22:02 dir/file1 -rwxrwxrwx 1 user group 0 2011-06-27 22:02 dir/file2 lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3 $ chmod 700 dir/* && ls -l dir/* /tmp/file3 -rwx------ 1 user group 0 2011-06-27 22:02 /tmp/file3 -rwx------ 1 user group 0 2011-06-27 22:02 dir/file1 -rwx------ 1 user group 0 2011-06-27 22:02 dir/file2 lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

astralblue · Answer

die Antworten von baraboom und peth sind beide richtig: Berechtigungsbits für die symbolischen Links selbst sind irrelevant (außer unter macOS; siehe unten), und das Ändern der Berechtigung für einen symbolischen Link - über das Befehlszeilentool chmod oder über den Systemaufruf chmod() - ist einfach Handeln Sie, als ob es gegen das Ziel der symbolischen Verknüpfung ausgeführt wurde.

Um die SUSv4/POSIX.1-2008-Beschreibung des Systemaufrufs symlink () zu zitieren :

Die Werte der Dateimodusbits für die erstellte symbolische Verknüpfung sind nicht angegeben. Alle von POSIX.1-2008 angegebenen Schnittstellen müssen sich so verhalten, als ob der Inhalt symbolischer Links immer gelesen werden kann, außer dass der Wert der im Feld st_mode des Felds stat zurückgegebenen Dateimodusbits Struktur ist nicht spezifiziert.

Hier lässt "nicht spezifiziert" Interpretationsspielraum für jede Implementierung. Besonderheiten:

Unter Linux (mit ext4fs getestet) gibt stat() st_mode=0777 zurück, unabhängig davon, wie die Umask lautete, als der Symlink erstellt wurde. ls -l zeigt daher bei symbolischen Links immer lrwxrwxrwx an.
Unter macOS (HFS) und FreeBSD (sowohl UFS als auch ZFS) verfügt eine symbolische Verknüpfung über eine eigene Berechtigung: Der oben erwähnte Befehl chmod -h kann diese Verknüpfungsberechtigung ändern (der intern einen Nicht-POSIX-Systemaufruf lchown() verwendet, um dies zu erreichen) Der Systemaufruf stat() gibt diesen Wert für st_mode zurück.

Symbolische Links unter Linux und FreeBSD können, wie von POSIX angegeben, immer befolgt werden. Insbesondere unter FreeBSD bedeutet dies, dass der Dateimodus einer symbolischen Verknüpfung keinerlei Auswirkung auf die Zugriffssteuerung hat.

Auf der anderen Seite unterbricht macOS POSIX leicht. Obwohl einem symbolischen Link unabhängig von seiner Leseberechtigung gefolgt werden kann, schlägt readlink() mit EACCES fehl (Berechtigung verweigert), wenn der Benutzer keine Leseberechtigung hat:

$ Sudo ln -shf target symlink $ Sudo chmod -h 444 symlink $ ls -l symlink lr--r--r-- 1 root staff 1 Mar 14 13:05 symlink -> target $ Sudo chmod -h 000 symlink $ ls -l symlink ls: symlink: Permission denied l--------- 1 root staff 1 Mar 14 13:05 symlink $ echo kthxbye > target $ cat symlink kthxbye

(Beachten Sie, dass der Teil -> target in der Ausgabe des zweiten Befehls ls -l fehlt und dass cat symlink weiterhin erfolgreich war und den Inhalt der Datei target druckte, obwohl der Benutzer keine Leseberechtigung für symlink hatte.)

NetBSD bietet anscheinend eine spezielle Einhängeoption mit dem Namen symperm an, die, falls gesetzt, symbolische Link-Lese-/Ausführungsberechtigungen zur Steuerung von readlink() und Link-Traversal hervorruft.