
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 chown
Befehls 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 chown
und chgrp
derselbe zugrunde liegende chown
Systemaufruf verwenden, der die Änderung von Besitzer und Gruppe ermöglicht. Der Systemaufruf führt die Berechtigungsprüfung durch. Der einzige Unterschied zwischen den Befehlen chown
und chgrp
ist 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 chown
folgendermaßen verwenden:
$ chown .saml afile
$ ls -l|grep afile
-rw-rw-r-- 1 saml saml 0 Oct 10 11:29 afile