Die POSIX - Spezifikation für das chown
Dienstprogramm erwähnt in ihrem Grundprinzip Abschnitt über die chown user:group
Syntax (früher chown user.group
) (Hervorhebung von mir):
Die 4.3 BSD-Methode zur Angabe von Eigentümer und Gruppe wurde in diesen Band von POSIX.1-2008 aufgenommen, weil:
- Es gibt Fälle, in denen die gewünschte Endbedingung mit den Dienstprogrammen chgrp und chown (die nur die Benutzer-ID geändert haben) nicht erreicht werden konnte. (Wenn der aktuelle Besitzer kein Mitglied der gewünschten Gruppe und der gewünschte Besitzer kein Mitglied der aktuellen Gruppe ist, kann die Funktion chown () fehlschlagen, sofern nicht sowohl der Besitzer als auch die Gruppe gleichzeitig geändert werden.)
Ich fand die user:group
Syntax praktisch. Das oben Gesagte impliziert, dass es Dinge gibt, mit chown user:group
denen Sie etwas tun können, mit denen Sie nichts anfangen könnenchgrp group; chown user
Nun, dieser Text ergibt für mich keinen Sinn. In 4.3BSD konnte nur root den Besitzer einer Datei ändern, so dass es auf keinen Fall Einschränkungen in Bezug auf die von ihm ausgeführten Aktionen gibt.
SysV und einige andere Systeme erlauben (oder erlauben) dem Eigentümer einer Datei, den Benutzer und die Gruppe einer Datei in irgendetwas zu ändern, aber selbst in diesen Systemen macht der obige Text für mich keinen Sinn. OK, wenn man a macht chown someone-else the-file
, kann man es nicht chgrp something-else the-file
nachträglich machen, weil man nicht länger der Eigentümer der Datei ist, aber es hindert ihn nichts daran, das chgrp
erste (den Eigentümer der Datei zu bleiben) und das chown
danach zu machen, und das ist nicht das Text oben sagt genau.
Ich verstehe nicht, was der und der gewünschte Eigentümer, der nicht Mitglied der aktuellen Gruppe ist, mit dem Problem zu tun hat.
Unter welchen Bedingungen kann die Funktion chown () fehlschlagen, wenn nicht gleichzeitig Eigentümer und Gruppe geändert werden , und auf welchem System?
chown me:my-group file
wenn sich die Datei an einem Speicherort befindet, an dem ich Lese- / Schreibzugriff habe (kein Sticky). Ich konnte nicht zuerst als nicht Besitzer chgrp. Ich konnte nicht zuerst chown, da dies zu einer Datei führen würde, die ich nicht erstellen konnte: Ich besitze eine Datei mit einer Gruppe, der ich nicht angehöre.Antworten:
Das Microsoft Interix Unix-Subsystem (inzwischen eingestellt) für seinen NT-Kernel hat mit Benutzer- und Gruppenberechtigungen etwas anders umgegangen als einige andere:
Hier sind einige spezifischere manuelle Auszüge:
Wie ich gelesen habe, bedeutet dies, dass, wenn Ihr Benutzerkonto zu einer Windows-Gruppe gehört, die über ausreichende Berechtigungen verfügt, um die Berechtigungen einer Datei zu ändern, deren Eigentümer diese Gruppe ist, diese
chgrp
Datei möglicherweise außerhalb der Kontrolle Ihres Benutzerkontos gespeichert wird. Dies bedeutet weniger Kontrolle als Sie möglicherweise mitchown
explizitenuser:group
Parametern haben. In diesem Zusammenhang ohne die Möglichkeit zu deklarierenuser:
und:group
Sie könnten nie die gleichen Ergebnisse wie sonst erzielen.Hier finden Sie einen Link zu einem detaillierten Einblick in die Interaktion von Interix mit Windows-ACLs, wobei der Schwerpunkt darauf liegt, wie sich diese Kenntnisse auf Samba-Dateisysteme in anderen Unix-Varianten auswirken können.
Hier ist ein Link zu einem inzwischen veralteten Solaris-Dokument, in dem
rstchown
das ...Anscheinend, wenn der Parameter auf einen Wert von
0
... gesetzt istEine solche Option macht die POSIX-Konformität von Solaris nicht ungültig . Nur dass es eine Option ist, qualifiziert es als konform :
Die
chown()
Systemfunktion - die der dokumentierten Systemaufruf von beiden hergestellt istchown
undchgrp
Shell - Utilities - wird angegeben scheitern aus mehreren Gründen. Darunter:Das Verhalten beim Gewähren von Rechten zum Ändern von Berechtigungen für Benutzer ohne Rootberechtigung war jedoch noch nie in Solaris einzigartig. Es gibt eine sehr gute - wenn auch etwas veraltete - Abdeckung der Unix-Dateiberechtigungen in diesem Forumsbeitrag, in dem der Autor Folgendes angibt:
Ein anderer guter - und neuerer - Mailinglisten-Beitrag zitiert dies und fährt fort:
Und wie Sie 2003 hervorheben :
... die von einem Konfigurationsparameter abhängt
setprivgroup
.In jedem Fall, in dem ein Benutzer ohne Rootberechtigung Dateiberechtigungen manipulieren kann, ist es denkbar, wie in der in Ihrer Frage angeführten Begründung erwähnt , dass ein Benutzer
chown
eine Datei sein könnte , die diesem Benutzer gehört, sodass sie einem anderen Benutzer gehört. Wenn der Gruppenbesitz der Datei und diechown
Gruppen des Benutzers nicht übereinstimmen, kann der Benutzer diese Datei nicht mehr ändern.In diesem Szenario
chown
dannchgrp
, wenn der Benutzer würden Berechtigungen fehlschlagen würde hat nicht mehr die Datei der Berechtigungen zu ändern, währendchown user:group
- solange Gruppe unter dem Benutzer eigenen - gelingen würde.Es gibt wahrscheinlich zahlreiche andere Nischensituationen, die sich in ähnlicher Weise ergeben könnten, darunter Verzeichnis- Sticky- und / oder Setgid- Bits, Dateisystem- und / oder implementierungsspezifische Zugriffssteuerungslisten. Dieser Thread ist zum Beispiel interessant. Die unzähligen Permutationen liegen weit jenseits meiner eigenen Vorstellungskraft - weshalb diese Antwort mit Füßen getreten ist. Wenn Sie dies lesen, glauben Sie, dass es wert ist, verbessert zu werden, und Sie glauben, dass Sie wissen, wie - bitte .
Es gibt auch eine ausführliche Dokumentation zu den verschiedenen möglichen Auswirkungen von Dateiberechtigungen, Tree Traversal und symbolischen Links, die hier einen ähnlichen Fehler in Bezug auf
-R
Ecursive-chown
Anwendungen verursachen können:Aus den POSIX XRAT- Abschnittsüberschriften Dritte und Vierte Domäne :
Und von der eigentlichen POSIX-
chgrp
Seite gibt es diese, die auf eine mögliche unvollständige-R
ecursive Aktion hinweist, oder zumindest auf das, was früher war :quelle
chgrp
chown
... verhalten sich möglicherweise nicht so, wie Sie es erwarten ...Annahme 1: Die Regeln, nach denen festgestellt wird, ob der
chown
Test erfolgreich ist, überprüfen die Teile des Zielbenutzers und der Gruppe unabhängig voneinander, dh, sie haben die Formuser_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)
.Annahme 2:
chown(file, -1, -1)
erfolgreich.Annahme 3: Die Regeln für den
chown
Erfolg hängen nicht davon ab, zu welcher Gruppe die Datei derzeit gehört.Fazit: Wenn
chown(file, uid, gid)
es gelingen würde, würde es gelingenchown(file, -1, gid) && chown(file, uid, -1)
.Ich kenne keine Unix-Variante, die gegen eine dieser Annahmen verstoßen würde, sie scheinen ziemlich sicher zu sein.
Dieser Satz sieht aus wie etwas, das jemand im Ausschuss sagte, als er nach stundenlanger Diskussion müde war, wie viele Optionen auf den Kopf eines
ps
Anrufs passen könnten - oder das die Sekretärin falsch geschrieben hat - und das niemand bei der Überprüfung erwischt hat. Schließlich gibt es noch andere gute Gründe, um zuzulassen, dass Benutzer und Gruppe automatisch geändert werden, einschließlich des Leistungsgrundes, der auch in der POSIX-Begründung genannt wird, sowie der Atomarität (ah, wenn nur ein einziger Aufruf zum Ändern von Eigentümern und Berechtigungen erfolgt wäre) ).Ein Fall, in dem Annahme 3 falsch sein könnte, liegt auf einem System vor, auf dem ein Prozess die Möglichkeit erhalten kann, Dateieigentümer zu ändern, jedoch nur, wenn sie über Schreibberechtigungen für die Datei verfügen. Obwohl dies etwas realistisch ist, kenne ich kein System, in dem dies der Fall ist. Dann kann
chgrp
eine Gruppe von einem Prozess, der weder als Root noch als Eigentümer der Datei ausgeführt wird, die Datei für einen späteren Zeitpunkt unbegrenzt machenchown
.Bei einem rekursiven Aufruf gibt es Randfälle, in denen ein vollständiger Durchlauf
chgrp
gefolgt von einem vollständigen Durchlaufchown
fehlschlagen kann, wenn ein einzelner Durchlauf erfolgreich wäre. Dies ist kein sehr überzeugendes Argument, da es sich um Verzeichnisse handelt, für die der Eigentümer nicht über die Berechtigung zum Durchsuchen verfügt, und eine Anwendung, die vor all diesen Fällen schützen möchte, ohnehin mit Berechtigungen experimentieren muss. Trotzdem erfüllt es technisch die Bedingung dieser Begründung. Angenommen, der ausgeführte Prozess verfügt über einen effektiven Benutzeralice
, eine effektive Gruppestaff
und die Fähigkeit, Dateibesitzer willkürlich zu ändern (nicht nur um sie preiszugeben; mehrere Unix-Varianten verfügen über eine solche Fähigkeit, obwohl sie nur selten Nicht-Root-Prozessen gewährt werden).quelle
chgrp
oderchown
könnte Nebenwirkungen haben, die die Fähigkeit beeinträchtigen, das andere zu tun. Zum Beispiel nimmtchown
die Fähigkeit zuchgrp
, das ist eine Tatsache.chgrp
löscht das setuid / setgid-Bit, es kann irgendeine Form von ACL oder eine andere Form von Sicherheitskontext löschen ...chown
gefolgt vonchgrp
scheitern könnte, aber die Frage ist überchgrp
gefolgt vonchown
. Hmmm, Sicherheitskontext ... könnte in einem System mit obligatorischer Zugriffskontrollechgrp
eine Datei verderben und sie nicht mehr chownierbar machen? Das scheint weit hergeholt.dir
, damit dies funktioniert,chown
müsste zuerst die Tiefe der Dateien verarbeiten, und ich kenne keine Implementierung, die dies tut. Es ist also ein beinahe gültiger Fall, in dem chgrp + chown fehlschlagen würde, wenn chmod u: g dies nicht könnte, aber das passt nicht wirklich zum Text der Begründung.chown
Theorien scheinen sich zu widersprechen.