Scheint, dass chown für Nicht-Root-Benutzer zulässig ist

Scheint, dass chown für Nicht-Root-Benutzer zulässig ist

Wir verwenden LDAP-Authentifizierung und wahrscheinlich noch andere Dinge, die ich in unserem Unternehmen nicht richtig verstanden habe. Daher sind möglicherweise die folgenden Fragen das Ergebnis davon. Ich habe ein seltsames Verhalten des chownBefehls festgestellt und weiß nicht, ob das normal ist. Hier ist mein Szenario:

Die GID des Benutzers Mark ist SK001936 und die Eigentümergruppe des Home-Verzeichnisses von Mark ist SK001778. Wie Sie sehen, sind sie nicht identisch. Die Gruppe SK001778 darf alle Operationen (rwx) mit dem Home-Verzeichnis des Benutzers Mark als Eigentümer ausführen (Mark hat):

[mark@machine ~]$ id
uid=48447(mark) gid=41795(SK001936) groups=40119(SUB_SK001936_PPS),41795(SK001936)
[mark@machine ~]$ ls -lad .
drwxrwxr-x   6 mark SK001778  4096 Oct 10 13:30 .

Die GIDs der Benutzer Michael und Mark sind beide SK001936:

[michael@machine mark]$ id
uid=40570(michael) gid=41795(SK001936) groups=40119(SUB_SK001936_PPS),41795(SK001936)
[mark@machine ~]$ id
uid=48447(mark) gid=41795(SK001936) groups=40119(SUB_SK001936_PPS),41795(SK001936)

Benutzer Michael kann keine Datei im Home-Verzeichnis von Benutzer Mark erstellen. Der Grund dafür ist, dass Michael nicht zur Gruppe (SK001778) gehört, die vollen (RWX-)Zugriff auf Marks Home-Verzeichnis hat:

[michael@machine mark]$ touch michael
touch: cannot touch `michael': Permission denied

Normalerweise kann der Benutzer den Chown nicht ausführen, selbst wenn er der Eigentümer der Datei ist. In diesem Beispiel kann der Eigentümer des Home-Verzeichnisses (Mark) jedoch die Eigentümergruppe seines eigenen Home-Verzeichnisses ändern (und damit den Benutzern dieser Gruppe Zugriff auf sein Home-Verzeichnis gewähren):

[mark@machine ~]$ chown mark:SK001936 .

Die Gruppe, die nun Zugriff auf das Home-Verzeichnis von Mark hat, ist somit dieselbe Gruppe wie die GID von Michael, daher ist es Michael nun gestattet, Dateien/Ordner im Home-Verzeichnis von Mark zu erstellen/löschen:

[michael@machine mark]$ touch michael

Mark kann den Gruppenbesitz seines Home-Verzeichnisses nicht zurückändern (denken Sie daran, dass nur Root den Befehl chown ausgeben darf):warum-kann-ein-normaler-benutzer-eine-datei-nicht-chownen):

[mark@machine ~]$ chown mark:SK001778 .
chown: changing ownership of `.': Operation not permitted

Meine Frage ist: Wie ist es möglich, dass Mark den Gruppenbesitz seines Home-Verzeichnisses ändern konnte, selbst wenn sierklärtdieser Chown kann nur von Root ausgegeben werden. Die Box ist RedHat 5.6.

Antwort1

Wenn Sie es auf eine Weise verwenden chown, bei der nur die Gruppe geändert wird, verhält es sich genauso wie chgrp. Der Besitzer einer Datei oder eines Verzeichnisses kann die Gruppe in jede beliebige Gruppe ändern, deren Mitglied er ist.

Dies funktioniert so, weil die Befehle chownund chgrpderselbe zugrunde liegende chownSystemaufruf verwenden, der die Änderung von Besitzer und Gruppe ermöglicht. Der Systemaufruf führt die Berechtigungsprüfung durch. Der einzige Unterschied zwischen den Befehlen chownund chgrpist die Syntax, mit der Sie die gewünschte Änderung angeben.

Mark kann die Gruppe nicht zurück auf SK001778 ändern, da er kein Mitglied der Gruppe SK001778 ist (und er ist nicht Root, was nicht durch die Gruppenmitgliedschaft eingeschränkt ist).

Antwort2

Benutzer können hiermit die Gruppe wechseln, sofern sie sich in einer dieser Gruppen befinden.

Beispiel

Angenommen, ich bin in den folgenden Gruppen:

$ groups
saml vboxusers jupiter newgrp

Und ich habe eine Datei:

$ ls -l | grep afile
-rw-rw-r--   1 saml saml        0 Oct 10 11:29 afile

also ändere ich die Gruppe dieser Datei wie folgt:L

$ chown saml.newgrp afile 

$ ls -l | grep afile
-rw-rw-r--   1 saml newgrp        0 Oct 10 11:29 afile

Sie können es auch chownfolgendermaßen verwenden:

$ chown .saml afile 

$ ls -l|grep afile
-rw-rw-r--   1 saml saml        0 Oct 10 11:29 afile

verwandte Informationen