Es hängt davon ab, wie Sie chmod aufrufen und die Plattform, auf der Sie laufen.
Beispiel:Auf einem Linux-System man chmod sagt dies:
chmod ändert niemals die Berechtigungen von symbolischen Links; die chmod Systemaufruf kann ihre Berechtigungen nicht ändern. Dies ist kein Problem, da die Berechtigungen von symbolischen Links niemals verwendet werden. Für jeden symbolischen Link, der in der Befehlszeile aufgeführt ist, chmod ändert die Berechtigungen der Datei, auf die gezeigt wird. Im Gegensatz dazu chmod ignoriert symbolische Links, die während rekursiver Verzeichnisdurchläufe auftreten.
Auf einem Mac kann chmod jedoch verwendet werden, um die Berechtigungen eines symbolischen Links mit Optionen wie dieser (von man chmod ):
-h Wenn die Datei ein symbolischer Link ist, ändert den Modus des Links selbst und nicht den Modus der Datei, auf die der Link zeigt.
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, wird das Linkziel nicht beeinflusst, aber wenn Sie chmod 777 directory/* tun , wird es.
Wenn Sie die Berechtigungen für das Linkziel direkt ändern, werden diese Berechtigungen übernommen (da die Manpage und Baraboom sagen, dass die eigentlichen 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
Die Antworten von baraboom und peth sind beide richtig:Berechtigungsbits auf den symbolischen Links selbst sind irrelevant (außer auf macOS; siehe unten), und das Ändern der Berechtigung auf einem symbolischen Link – durch den chmod Befehlszeilentool oder durch chmod() Systemaufruf – verhält sich einfach so, als wäre er gegen das Ziel des symbolischen Links ausgeführt worden.
Um die SUSv4/POSIX.1-2008-Beschreibung des symlink()-Systemaufrufs zu zitieren:
Die Werte der Dateimodusbits für die erstellte symbolische Verbindung sind nicht spezifiziert. Alle von POSIX.1-2008 spezifizierten Schnittstellen sollen sich so verhalten, als ob der Inhalt symbolischer Links immer gelesen werden kann, außer dass der Wert der Dateimodusbits in st_mode zurückgegeben wird Feld der Statistik Struktur ist nicht spezifiziert.
„Unspezifiziert“ lässt hier Interpretationsspielraum für jede Umsetzung. Besonderheiten:
- Unter Linux (getestet mit ext4fs),
stat()gibtst_mode=0777zurück , egal was die Umask war, als der Symlink erstellt wurde;ls -lzeigt daher immerlrwxrwxrwxan für symbolische Links. - Auf macOS (HFS) und FreeBSD (sowohl UFS als auch ZFS) hat ein symbolischer Link seine eigene Berechtigung:Der
chmod -hDer oben erwähnte Befehl kann diese Linkberechtigung ändern (die intern einen Nicht-POSIX-lchown()verwendet Systemaufruf, um dies zu erreichen) und derstat()Der Systemaufruf gibt diesen Wert fürst_modezurück .
Symbolischen Links unter Linux und FreeBSD kann immer gefolgt werden, wie von POSIX angegeben. Insbesondere unter FreeBSD bedeutet dies, dass der Dateimodus eines symbolischen Links keinerlei Einfluss auf die Zugriffskontrolle hat.
Auf der anderen Seite unterbricht macOS POSIX leicht. Obwohl einem symbolischen Link unabhängig von seiner Leseberechtigung gefolgt werden kann, readlink() schlägt 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 die -> target Teil fehlt in der Ausgabe des zweiten ls -l Befehl, und das cat symlink trotzdem erfolgreich und druckte den Inhalt der target Datei, obwohl der Benutzer keine Leseberechtigung für symlink hatte .)
NetBSD bietet anscheinend eine spezielle Mount-Option namens symperm an was, wenn es gesetzt ist, bewirkt, dass Lese-/Ausführungsberechtigungen für symbolische Links readlink() steuern und Link-Traversal.