Warum darf rm eine Datei löschen, die einem anderen Benutzer gehört?

Aus dem Beitrag Warum kann rm schreibgeschützte Dateien entfernen? Ich verstehe, dass rmnur Schreibberechtigung für Verzeichnis benötigt, um die Datei zu entfernen. Aber ich finde es schwierig, das Verhalten zu verdauen, bei dem wir leicht eine Datei löschen können, deren Eigentümer und Gruppe unterschiedlich sind.

Ich habe folgendes versucht

mtk: mein benutzername
abc: hat einen neuen benutzer erstellt

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

Ich dachte, das hätte nicht erlaubt sein dürfen. Ein Benutzer sollte in der Lage sein, nur Dateien zu löschen, die sich in seinem Besitz befinden. Kann jemand Aufschluss darüber geben, warum dies zulässig ist? und wie kann man das vermeiden? Ich kann denken, nur die Schreibberechtigung des übergeordneten Verzeichnisses zu beschränken, um überraschte Löschungen der Datei zu deaktivieren.

— mtk
quelle

Antworten:

100

Der Grund, warum dies zulässig ist, hängt davon ab, was das Entfernen einer Datei tatsächlich bewirkt. Konzeptionell besteht rmdie Aufgabe darin, einen Namenseintrag aus einem Verzeichnis zu entfernen. Die Tatsache, dass die Datei dann unter Umständen nicht mehr erreichbar ist, wenn dies der einzige Name der Datei war und der von der Datei belegte Inode und Speicherplatz an dieser Stelle wiederhergestellt werden kann, ist fast zufällig. Der Name des Systemaufrufs, den der rmBefehl aufruft unlink, weist sogar auf diese Tatsache hin.

Das Entfernen eines Namenseintrags aus einem Verzeichnis ist im Grunde eine Operation in diesem Verzeichnis , sodass Sie zum Schreiben dieses Verzeichnisses über die erforderliche Berechtigung verfügen müssen.

Mit dem folgenden Szenario fühlen Sie sich möglicherweise wohler? Angenommen, es gibt Verzeichnisse:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

Und es gibt eine Datei, die mir gehört und die zwei feste Links hat:

/home/me/myfile
/home/you/myfile

Egal, wie diese harte Verbindung überhaupt /home/you/myfiledorthin gekommen ist. Vielleicht rootlegen Sie es dort.

Die Idee dieses Beispiels ist, dass Sie den festen Link entfernen dürfen /home/you/myfile. Immerhin ist es Ihr Verzeichnis überfüllt . Sie sollten in der Lage sein zu kontrollieren, was im Inneren existiert und was nicht /home/you. Beachten Sie beim Entfernen /home/you/myfile, dass Sie die Datei nicht tatsächlich gelöscht haben. Sie haben nur einen Link entfernt.

Beachten Sie, dass Sie der Eigentümer der Datei sein müssen , wenn das Sticky-Bit in dem Verzeichnis gesetzt ist, das eine Datei enthält (wird angezeigt wie tin ls), damit Sie sie löschen können (es sei denn, Sie besitzen das Verzeichnis). Das Sticky-Bit ist normalerweise aktiviert /tmp.

— Celada
quelle

Mit dem Sticky-Bit im Verzeichnis müssen Sie in der Lage sein, die Datei zu ändern, damit Sie sie entfernen können. Das heißt, wenn die Datei einer anderen Person in derselben Gruppe gehört wie Sie und die Gruppe möglicherweise in die Datei schreibt, können Sie die Datei entfernen. Fazit: Jeder kann eine Datei mit öffentlichen Schreibrechten entfernen. (Alle vorbehaltlich der Möglichkeit, das Verzeichnis zu ändern, natürlich.)

— Jonathan Leffler

Ich kann Sie falsch interpretieren, aber sagen Sie dann nicht, dass ich -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/fooals mein normaler Benutzer entfernen kann ( /tmpklebrig ist), weil ich es schreiben darf? Ich kann es aber nicht.

— Celada

Ich glaube, dass das me/ you-Szenario klarer in den Fokus gerät, wenn Sie die Hypothese aufstellen, dass der Benutzer (derjenige, dem die Datei nicht gehört) den Link erstellt hat. Pronomen sind schwer zu gebrauchen; Nehmen wir an, Al erstellt eine Datei /home/al/file1, und Bob, der Zugriff auf diese /home/alDatei ausgeführt (und möglicherweise gelesen) hat , verknüpft sie fest mit der Datei /home/bob/als_file. Sollte Bob aus Entfernen einer Verbindung verhindert werden , dass er geschaffen? Und sollte Al das Löschen (Unlink) erlauben, /home/bob/als_filewenn er keinen Schreibzugriff hat /home/bob? Diese Straße führt ins Chaos.

— Scott

@JonathanLeffler: Wie das Beispiel von Scott zeigt, führen das Aufheben und Abschneiden von Verknüpfungen nicht zum gleichen Nettoergebnis, wenn harte Verknüpfungen im Spiel sind.

— Kevin

@ Kevin Ich denke, der Punkt ist, dass, wenn jemand eine Schreibberechtigung für die Datei hat, so dass er den Inhalt zerstören kann, er genauso gut die Verknüpfung aufheben kann (vorausgesetzt, er hat auch eine Schreibberechtigung für das Verzeichnis). Die Umkehrung trifft nicht zu. Wenn er die Datei aus einem Verzeichnis entfernen kann, bedeutet dies nicht, dass er den Inhalt zerstören kann, da er möglicherweise von einem anderen Verzeichnis aus darauf zugreifen kann. Dies ist die Logik dahinter, wie das Sticky Bit funktioniert.

— Barmar

Um eine Datei zu entfernen, müssen Sie nur in das Verzeichnis schreiben können, in dem sich die Datei befindet.

Wenn Ihnen das nicht gefällt, können Sie das "Sticky" -Bit über setzen, chmod +t dirwenn Sie sich auf einem Betriebssystem befinden, das zur Hälfte neu ist (diese Funktion wurde um 1986 in SunOS eingeführt).

Wenn Sie feinkörniger sein möchten, benötigen Sie ein Dateisystem mit einer modernen ACL-Implementierung wie ZFS. Die auf NTFS basierenden Standard-NFSv4-ACLs unterstützen dateispezifische Löschberechtigungen pro Benutzer und die Berechtigung "delete_child" für Verzeichnisse.

— schily
quelle

Beachten Sie, dass tSie das Verzeichnis besitzen müssen , um das Bit hinzuzufügen . Und wenn Sie das Verzeichnis besitzen, können Sie immer Dateien entfernen, unabhängig davon, ob das tBit gesetzt ist oder nicht. Wenn Sie eine Datei mit dem Verzeichnis einer anderen Person verknüpfen, sollten Sie darauf vorbereitet sein, dass eine andere Person sie entfernen kann. Eine Alternative wäre, zuerst ein Unterverzeichnis von Ihnen zu erstellen und stattdessen Ihre Datei dort hinzuzufügen, da der Eigentümer dieses Unterverzeichnis nicht entfernen kann, wenn es nicht leer ist.

— Stéphane Chazelas

Sie beschreiben die Situation auf irreführende Weise. Technisch gesehen befindet sich eine Datei nicht in einem Verzeichnis. Ein Name für eine Datei befindet sich im Verzeichnis und rmist eine Operation für das Verzeichnis und nicht für die Datei. Eine Datei wird zwar entfernt, wenn der letzte Verweis darauf entfernt wird, dies ist jedoch technisch gesehen ein Nebeneffekt.

— Reinierpost

Die Logik ähnelt der eines Hauses: Der Eigentümer oder Mieter entscheidet, welche Gäste weggeworfen werden, unabhängig davon, wem die Gäste gehören. Außerdem friert der vertriebene Gast, der in einem anderen Haus willkommen ist (mit einem anderen Hardlink im Verzeichnis einer anderen Person), draußen nicht zu Tode.

— Rackandboneman
quelle