Wer kann die Berechtigungen einer Datei / eines Verzeichnisses ändern?


14

Ich glaube (nicht sicher), dass der Eigentümer einer Datei / eines Verzeichnisses und der Root-Benutzer die einzigen Benutzer sind, die die Berechtigungen einer Datei / eines Verzeichnisses ändern dürfen. Bin ich korrekt oder gibt es andere Benutzer, die ebenfalls die Berechtigungen ändern dürfen?

Antworten:


19

Nur der Eigentümer und root(Superuser) dürfen die Berechtigung einer Datei oder eines Verzeichnisses ändern. Dies bedeutet, dass der Eigentümer und der Superuser die Berechtigungen read ( r), write ( w) und execute ( x) festlegen können . Das Ändern des Eigentums (Benutzer / Gruppe) von Dateien und Verzeichnissen mit den Befehlen chown/ chgrpist jedoch nur zulässig root.


19
Der Eigentümer einer Datei kann den Gruppeneigentum dieser Datei ändern, wenn der Benutzer Mitglied der neuen Gruppe ist.
Kusalananda

7

Für den normalen Betrieb können nur root und der Eigentümer chmod. Darüber hinaus können root chownund chgrpund weiterhin der Eigentümer, chgrpsolange der Eigentümer Mitglied der Zielgruppe ist.

Aus Sicherheitsgründen gibt es jedoch einen anderen Fall: Jeder Benutzer mit Schreibberechtigung für das Verzeichnis, in dem sich die Datei befindet, kann die Datei durch eine Kopie ersetzen und so Eigentümer werden, sodass er die Berechtigungen und Inhalte ändern kann.

Wie so:

14:14 mybox:~ mkdir mydir
14:14 mybox:~ cd mydir/
14:14 mybox:mydir echo foo | sudo tee yourfile
foo
14:14 mybox:mydir ls -ld . yourfile 
drwxr-xr-x  3 me    staff  102 Apr 11 14:14 .
-rw-r--r--  1 root  staff    4 Apr 11 14:14 yourfile

Wir haben ein Verzeichnis erstellt und eine Datei als root geschrieben. Da root die Datei besitzt, können wir weder darauf schreiben, noch können wir chmod:

14:15 mybox:mydir echo bar > yourfile 
-bash: yourfile: Permission denied
14:15 mybox:mydir chmod a+x yourfile
chmod: Unable to change file mode on yourfile: Operation not permitted

Wir haben jedoch eine Schreibberechtigung für das Verzeichnis, sodass wir die Datei ersetzen können, um den Besitz zu erlangen:

14:15 mybox:mydir mv yourfile yourfile2
14:15 mybox:mydir cp yourfile2 yourfile
14:15 mybox:mydir ls -ld . yourfile 
drwxr-xr-x  4 me   staff  136 Apr 11 14:15 .
-rw-r--r--  1 me   staff    4 Apr 11 14:15 yourfile

Und jetzt, da wir der Eigentümer sind, können wir natürlich mit dieser Datei machen, was wir wollen:

14:15 mybox:mydir echo bar > yourfile 
14:15 mybox:mydir chmod a+x yourfile
14:16 mybox:mydir cat yourfile
bar

Ebenso kann jeder Benutzer mit Schreibberechtigung für ein beliebiges Verzeichnis im vollständigen Pfad, der zur Datei führt, die Verzeichnisstruktur ab diesem Zeitpunkt ersetzen und so den Besitz der Datei mit dem angegebenen Namen erlangen. Der Besitz oder die Berechtigungen der tatsächlichen Originaldatei (die wir in "yourfile2" umbenannt haben) werden natürlich nicht geändert.

14:17 mybox:mydir ls -l yourfile2
-rw-r--r--  1 root  staff  4 Apr 11 14:14 yourfile2

Wissen Sie, ob eine Linux-Distribution zusätzliche Sicherheitsfunktionen wie Windows unterstützt? Unter Windows kann ich festlegen, dass die Löschberechtigung einer Datei verweigert wird, um das Löschen zu verhindern, auch wenn das Verzeichnis zulässig ist.
Kevin Li

Viele (die meisten?) Aktuellen Linux-Versionen unterstützen Zugriffssteuerungslisten auf Dateiebene ( getfacl / setfacl), die mehr Flexibilität bieten als die klassischen Dateiberechtigungen. Das Löschen von Dateien in * nix erfolgt durch Entfernen des Links zu der Datei aus dem Verzeichnis. Das Entfernen von Dateien wird also immer durch die Verzeichnisberechtigungen gesteuert. Die Dateiberechtigungen selbst spielen dort keine Rolle.
Bass

Ganz der Unix-Philosophie treu: „Alles ist eine Datei.“ Sie sagen also, dass so etwas unter Linux nicht möglich ist?
Kevin Li

3
@ KevinLi Diese Antwort ist nicht wirklich vollständig. Sie können das Sticky-Bit für ein Verzeichnis festlegen , um die Fähigkeit von Nicht-Besitzern zu begrenzen, Dateien zu löschen oder umzubenennen. Sehen Sie sich diese Frage und ihre Antworten an: unix.stackexchange.com/questions/79395/… Es ist nicht erforderlich, ACLs oder andere Schemata zu verwenden.
Andrew Henle

@KevinLi * nix-Dateisysteme unterscheiden sich stark von denen von Windows. Die Dateien existieren getrennt von der Verzeichnishierarchie und können mehrere "feste Verknüpfungen" aufweisen, die auf sie in den Verzeichnissen verweisen. Das Löschen einer Datei bedeutet tatsächlich das Entfernen der festen Verknüpfung, die für das Verzeichnis durchgeführt wird. Die Datei protokolliert, wie viele Hardlinks darauf verweisen, und die eigentliche Datei verbleibt auf der Festplatte, solange mindestens ein Hardlink darauf verweist. Somit wird Löschung durch die Verzeichnisberechtigungen gesteuert, die Sie eine spezielle Option müssen nur Löschungen von Dateibesitzer & root erlauben, wie Andrew sagt.
Bass

1

Der chmodBefehl ruft den Systemaufruf mit demselben Namen ziemlich direkt auf. Die Manpage für den chmod(2)Systemaufruf (unter Linux 4.10) lautet:

Die effektive UID des aufrufenden Prozesses muss mit dem Eigentümer der Datei übereinstimmen, oder der Prozess muss privilegiert sein (Linux: Er muss die CAP_FOWNERFähigkeit haben).

Wenn der aufrufende Prozess nicht privilegiert ist (Linux: hat nicht die CAP_FSETIDFähigkeit) und die Gruppe der Datei nicht mit der effektiven Gruppen-ID des Prozesses oder einer seiner zusätzlichen Gruppen-IDs übereinstimmt, wird das S_ISGIDBit deaktiviert, dies jedoch wird nicht dazu führen, dass ein Fehler zurückgegeben wird.

Ja, ein Prozess, der als Root ausgeführt wird, kann die Berechtigungen einer Datei ändern, wenn die CAP_FOWNERFunktion nicht gelöscht wurde .


Interessant ist auch chown; Die Manpage für chown(2)sagt:

Nur ein privilegierter Prozess (Linux: einer mit der CAP_CHOWNFähigkeit) kann den Eigentümer einer Datei ändern. Der Eigentümer einer Datei kann die Gruppe der Datei in eine beliebige Gruppe ändern, zu der dieser Eigentümer gehört. Ein privilegierter Prozess (Linux: mit CAP_CHOWN) kann die Gruppe beliebig ändern.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.