Erklärung zu chown (1) POSIX spec

18

Die POSIX - Spezifikation für das chownDienstprogramm erwähnt in ihrem Grundprinzip Abschnitt über die chown user:groupSyntax (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:groupSyntax praktisch. Das oben Gesagte impliziert, dass es Dinge gibt, mit chown user:groupdenen 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-filenachträglich machen, weil man nicht länger der Eigentümer der Datei ist, aber es hindert ihn nichts daran, das chgrperste (den Eigentümer der Datei zu bleiben) und das chowndanach 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?

Stéphane Chazelas
quelle
1
@ Robert, auf welches System würden diese Regeln zutreffen? Auf den Systemen, die ich kenne, sind Sie entweder root und können tun, was Sie wollen, oder Sie sind nicht user1 und können nichts tun. Wenn Sie Benutzer1 sind, können Sie je nach System den Eigentümer nicht ändern, oder wenn Sie können, können Sie die Gruppe nach Belieben und den Benutzer nach Belieben ändern.
Stéphane Chazelas
Wenn ich in einem Verzeichnis, das mir gehört, eine Datei habe, die jemand anderem gehört, und eine Gruppe, der ich nicht angehöre, die ich jedoch aufgrund anderer Berechtigungen lesen kann. Dann ist es mir möglich, es zu kopieren, um mich zum Besitzer zu machen, und es hat eine neue Gruppe (für die ich Mitglied bin). Daher muss es für das Betriebssystem so sicher sein, dass es mir als Nicht-Root erlaubt wird, chown me:my-group filewenn 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.
Strg-Alt-Delor
@richard, nein es wäre nicht so sicher . Diese Datei ist möglicherweise fest mit einem anderen Verzeichnis verknüpft, auf das Sie keinen Zugriff haben. Auf Systemen, auf denen Sie Dateien verknüpfen können, die Sie nicht besitzen (z. B. standardmäßig Linux), können Sie den Besitz einer beliebigen Datei beanspruchen, indem Sie sie mit einem Verzeichnis verknüpfen, auf das Sie Schreibzugriff haben.
Stéphane Chazelas
Ich habe diesen Text gefunden, der auch erklärt, warum ich falsch liege (es ist nicht so sicher): „Wenn Sie die Datei aneignen könnten, wäre dies eine Sicherheitslücke. Zum Beispiel könnte der Benutzer jemand die Datei öffnen, dann ihren Besitz und ihre Berechtigungen überprüfen (indem er fstat für das Handle der geöffneten Datei aufruft) und daraus schließen, dass nur ein Programm, das als jemand ausgeführt wird, diese Daten hätte produzieren können. Wenn Sie in der Lage wären,
ändern

Antworten:

5

Das Microsoft Interix Unix-Subsystem (inzwischen eingestellt) für seinen NT-Kernel hat mit Benutzer- und Gruppenberechtigungen etwas anders umgegangen als einige andere:

Benutzer- und Gruppeninformationen werden in der Security Access-Datenbank gespeichert . Sowohl Benutzer als auch Gruppen werden in derselben Datenbank gespeichert, aber Gruppen- und Benutzernamen müssen eindeutig sein. Keine Gruppe kann einen Benutzernamen haben und umgekehrt. (Diese Datenbank ersetzt die /etc/passwdund /etc/groups-Dateien in UNIX.) Benutzer und Gruppen werden mit der entsprechenden Windows-Methode (Benutzermanager, Active Directory-Benutzer und -Computer oder Lokale Benutzer und Gruppen) oder mit dem Win32- net userBefehl erstellt. (Beispielshellskripte zum Erstellen und Entfernen von Benutzern sind im Verzeichnis enthalten /usr/examples/admin.) Benutzer können vielen Gruppen angehören.

Hier sind einige spezifischere manuelle Auszüge:

In Windows kann entweder ein Benutzer oder eine Gruppe ein Objekt besitzen. Dies unterscheidet sich von UNIX, bei dem nur ein Benutzer ein Objekt besitzt.

Windows identifiziert alle Benutzer und Gruppen intern mithilfe einer Sicherheitskennung (SID) . Ein Hashing-Algorithmus generiert eindeutige SID-Werte. Keine zwei Benutzer oder Gruppen haben dieselbe SID.

Benutzer und Gruppen, die zum Zugriff auf ein Objekt berechtigt sind, werden anhand ihrer SID identifiziert. Alle Objekte, die von Windows gesichert werden können, verfügen über eine DACL (Discretionary Access Control List), die aus separaten Einträgen (Access Control Entries, ACEs) besteht. Ein ACE enthält zwei wichtige Informationen: eine Benutzer- oder Gruppen-SID und eine Beschreibung, wie viel Zugriff der einzelne Benutzer oder die Gruppe auf ein Objekt hat.

CHGRP

... Ändern Sie die Gruppen-ID für die Datei ... Der Benutzer, der chgrp (1) aufruft, muss der angegebenen Gruppe angehören und der Eigentümer der Datei sein oder über die entsprechenden Berechtigungen verfügen.

CHOWN

... Die Operanden owner und group sind beide optional. es muss jedoch einer angegeben werden. Wenn der Gruppenoperand angegeben ist, muss ein Doppelpunkt (:) vorangestellt werden.

Der Eigentümer kann entweder durch eine numerische Benutzer-ID oder einen Benutzernamen angegeben werden. Wenn ein Benutzername auch eine numerische Benutzer-ID ist, wird der Operand als Benutzername verwendet. Die Gruppe kann entweder eine numerische Gruppen-ID oder ein Gruppenname sein. Wenn ein Gruppenname auch eine numerische Gruppen-ID ist, wird der Operand als Gruppenname verwendet.

Aus Sicherheitsgründen kann der Besitz einer Datei nur durch einen Prozess mit entsprechenden Berechtigungen geändert werden.

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 chgrpDatei möglicherweise außerhalb der Kontrolle Ihres Benutzerkontos gespeichert wird. Dies bedeutet weniger Kontrolle als Sie möglicherweise mit chownexpliziten user:groupParametern haben. In diesem Zusammenhang ohne die Möglichkeit zu deklarieren user: 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 rstchowndas ...

Gibt an, ob die POSIX-Semantik für den chown(2)Systemaufruf wirksam ist.

Anscheinend, wenn der Parameter auf einen Wert von 0... gesetzt ist

... das Ausschalten der POSIX-Semantik eröffnet das Potenzial für verschiedene Sicherheitslücken. Es eröffnet auch die Möglichkeit, dass ein Benutzer den Besitz einer Datei auf einen anderen Benutzer ändert und die Datei nicht ohne Eingreifen des Benutzers oder des Systemadministrators zurückrufen kann.

Eine solche Option macht die POSIX-Konformität von Solaris nicht ungültig . Nur dass es eine Option ist, qualifiziert es als konform :

Obwohl alle Implementierungen gemäß POSIX.1-2008 alle unten beschriebenen Funktionen unterstützen, gibt es möglicherweise systemabhängige oder dateisystemabhängige Konfigurationsverfahren, mit denen einige oder alle dieser Funktionen entfernt oder geändert werden können. Solche Konfigurationen sollten nicht vorgenommen werden, wenn eine strikte Einhaltung erforderlich ist.

Die folgenden symbolischen Konstanten müssen mit einem anderen Wert als -1 definiert werden. Wenn eine Konstante mit dem Wert Null festgelegt wird, sollen die Anwendungen verwenden sysconf(), pathconf()oder fpathconf()Funktionen, oder das getconfDienstprogramm, um zu bestimmen , welche Funktionen sind auf dem System zu diesem Zeitpunkt oder für die jeweiligen Pfadnamen in Frage.

_POSIX_CHOWN_RESTRICTED

Die Verwendung von chown()ist auf einen Prozess mit entsprechenden Berechtigungen beschränkt. Die Gruppen-ID einer Datei darf nur in die effektive Gruppen-ID des Prozesses oder in eine der zusätzlichen Gruppen-IDs geändert werden.

Die chown()Systemfunktion - die der dokumentierten Systemaufruf von beiden hergestellt ist chownund chgrpShell - Utilities - wird angegeben scheitern aus mehreren Gründen. Darunter:

EACCES Die Suchberechtigung wird für eine Komponente des Pfadpräfixes verweigert.

ELOOP In symbolischen Links, die während der Auflösung des Pfadarguments auftreten, ist eine Schleife vorhanden.

EPERM Die effektive Benutzer-ID stimmt nicht mit dem Eigentümer der Datei überein, oder der aufrufende Prozess verfügt nicht über die entsprechenden Berechtigungen, und _POSIX_CHOWN_RESTRICTED gibt an, dass diese Berechtigungen erforderlich sind.

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:

Ursprünglich erlaubte Unix einem Dateieigentümer, eine Datei weiterzugeben. Der Eigentümer einer Datei kann den Eigentümer in einen anderen ändern. Es gab keine Möglichkeit für einen Nicht-Root-Benutzer, diese Operation rückgängig zu machen ... BSD [später] wurde chownvon Nicht-Root-Benutzern entfernt ... [zum Teil, weil] ... Festplattenkontingente implementiert wurden, die die Größe des Festplattenspeichers einschränken konnten Benutzer könnte in einem Dateisystem haben ... Freche Benutzer könnten große Dateien verschenken, um hinter die Quoten zu schauen.

Heutzutage ist es nicht einfach zu sagen, ob chowneine Datei von einem Nicht-Root-Benutzer erstellt werden kann . Viele Versionen von Unix erlauben beide Verhaltensweisen ...

Ein anderer guter - und neuerer - Mailinglisten-Beitrag zitiert dies und fährt fort:

Die Standardeinstellung bei den meisten Betriebssystemen ist chown, dass sie nur auf root beschränkt sind. Und es besteht Einigkeit darüber, dass dies aus Sicherheitsgründen auch so bleiben sollte. Wenn ein Nicht-Root - Benutzer den Besitzer einer Datei ändert und jeder Execute - Bit ist auf den SUIDund SGIDmüssen Bits gelöscht werden. Dies kann passieren oder auch nicht root.

Ich denke, dass der letzte Absatz es schön sagt.

In diesem Artikel wird auch CAP_CHOWNauf die Steuerung dieser Funktion unter Linux verwiesen (dies sollte sich nur auf das POSIX_CHOWN_RESTRICTEDVerhalten auswirken ) . Es gibt auch die CAP_FOWNERFähigkeit, die im Verhalten etwas anders ist.

Und wie Sie 2003 hervorheben :

Beachten Sie, dass Sie zumindest unter HPUX den Eigentümer Ihrer Dateien ändern können (zum rootBeispiel), auch wenn Sie kein privilegierter Benutzer sind ...

... 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 chowneine Datei sein könnte , die diesem Benutzer gehört, sodass sie einem anderen Benutzer gehört. Wenn der Gruppenbesitz der Datei und die chownGruppen des Benutzers nicht übereinstimmen, kann der Benutzer diese Datei nicht mehr ändern.

In diesem Szenario chown dann chgrp , wenn der Benutzer würden Berechtigungen fehlschlagen würde hat nicht mehr die Datei der Berechtigungen zu ändern, während chown 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 -REcursive- chownAnwendungen verursachen können:

Aus den POSIX XRAT- Abschnittsüberschriften Dritte und Vierte Domäne :

Im Allgemeinen werden Benutzer, die die Option für eine Dateihierarchieüberquerung angeben, ignoriert, um eine einzelne physische Hierarchie zu bearbeiten, und daher werden symbolische Verknüpfungen, die auf Dateien außerhalb der Hierarchie verweisen können, ignoriert. Chown owner file ist beispielsweise eine andere Operation als derselbe Befehl mit der angegebenen Option -R. In diesem Beispiel wird das Verhalten des Befehls chown owner filehier beschrieben, während das Verhalten der Befehlseignerdatei chown -Rin der dritten und vierten Domäne beschrieben wird.

... Es gibt ein Sicherheitsproblem bei der Standardeinstellung eines logischen Ablaufs. In der chown -RVergangenheit war die Befehlsbenutzerdatei für den Superuser sicher, da die Bits setuid und setgid verloren gingen, als der Besitz der Datei geändert wurde. Wenn der Spaziergang logisch wäre, wäre ein Eigentümerwechsel nicht mehr sicher, da ein Benutzer möglicherweise einen symbolischen Link eingefügt hat, der auf eine Datei in der Baumstruktur verweist. Dies würde wiederum die Hinzufügung einer Option zu den Befehlen erfordern, die die Hierarchie so durchlaufen, dass sie nicht indirekt über die symbolischen Verknüpfungen erfolgen, und historische Skripten, die rekursive Durchläufe ausführen, würden sofort zu Sicherheitsproblemen. Dies ist zwar hauptsächlich ein Problem für Systemadministratoren, es ist jedoch vorzuziehen, für verschiedene Benutzerklassen keine unterschiedlichen Standardeinstellungen festzulegen.

...

In 4.3 BSD wurde chgrpbeim Durchlaufen des Baums die Gruppe der symbolischen Verknüpfung geändert, nicht das Ziel. Symbolische Links in 4.4 BSD hatten keine Eigentümer-, Gruppen-, Modus- oder anderen Standard-UNIX-Systemdateiattribute.

Und von der eigentlichen POSIX- chgrpSeite gibt es diese, die auf eine mögliche unvollständige -Recursive Aktion hinweist, oder zumindest auf das, was früher war :

Die Versionen System V und BSD verwenden unterschiedliche Beendigungsstatuscodes. Bei einigen Implementierungen wurde der Exit-Status als Anzahl der aufgetretenen Fehler verwendet. Diese Vorgehensweise ist nicht praktikabel, da sie den Bereich der gültigen Exit-Statuswerte überschreiten kann. Die Standardentwickler haben diese maskiert, indem sie nur 0 und> 0 als Exit-Werte angegeben haben.

U / min mikeserv
quelle
1
@StephaneChazelas - froh, dass Sie verstanden haben. "Das ist ein bisschen chaotisch, weil ich nicht sehr gut mit der ganzen Berechtigungssache umgehen kann - besonders wenn es um SE-Attribute geht." Die Verbindung ist lose - Links! = Ch {grp, own}, aber ich dachte mir, wenn die POSIX-Leute sich so viel Mühe geben würden, es zu formulieren (es gibt auch eine große Tabelle auf der Seite), dann aus dem gleichen Grund könnte ein Link Probleme bereiten dann also möglicherweise zwei -R-Aktionen. Es würde nichts kaputt machen, wenn Sie beide Füße in - Benutzer und Gruppe - haben, wie Sie sagen, aber wenn Sie bereits 1 weg sind. Wie auch immer, ich wikied es aus einem Grund. Nicht wirklich meine Stärke. Es tut uns leid.
mikeserv
1
Guter Punkt, ich hatte nicht an -R gedacht. Man könnte sich vorstellen, dass Sie auf dem chgrp den Such- oder Lesezugriff auf ein Verzeichnis verlieren könnten, was Sie daran hindern würde, die Berechtigungen von Dateien dort zu ändern, aber andererseits kann ich mit den traditionellen Unix-Möglichkeiten, mit Eigentumsrechten oder Berechtigungen umzugehen, nicht sehen, wie es möglich machen. Ein weiterer Bereich, der meiner Meinung nach untersucht werden sollte, sind die NFSv4-ACLs auf Systemen, die dies unterstützen (Solaris, FreeBSD, SUSE ...)
Stéphane Chazelas,
@ StéphaneChazelas - Gibt es einen Aspekt Ihrer Frage, den dieser Beitrag nicht beantwortet?
mikeserv
Vielen Dank für die gründliche Recherche. Es wäre schön, wenn Sie ein Beispiel mit dem NT Unix-Subsystem hinzufügen könnten, in dem der POSIX-Text angewendet wird. Ich bin mir nicht sicher, wie Kopfgelder mit Community-Wiki-Antworten funktionieren. Ich werde es versuchen.
Stéphane Chazelas
@ StéphaneChazelas - Ich habe mich nicht um die Punkte gekümmert und nie. Ich hatte nur gehofft, ich hätte es nicht vermasselt. Ich bin nicht sicher, ob ich das bekomme, aber es wäre ein schöner Teil - meinst du NT Unix 4? Microsofts offizielle Dokumente behaupten, POSIX-Konformität zu haben, zumindest, als es noch Interix war. Ich und sie behaupten etwas seltsam chgrp chown... verhalten sich möglicherweise nicht so, wie Sie es erwarten ...
mikeserv
1

Annahme 1: Die Regeln, nach denen festgestellt wird, ob der chownTest erfolgreich ist, überprüfen die Teile des Zielbenutzers und der Gruppe unabhängig voneinander, dh, sie haben die Form user_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 chownErfolg 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 gelingen chown(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 psAnrufs 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 chgrpeine 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 machen chown.


Bei einem rekursiven Aufruf gibt es Randfälle, in denen ein vollständiger Durchlauf chgrpgefolgt von einem vollständigen Durchlauf chownfehlschlagen 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 Benutzer alice, eine effektive Gruppe staffund 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).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied
Gilles 'SO - hör auf böse zu sein'
quelle
Beachten Sie, dass es bei POSIX nicht nur um Unix geht. Es gibt viele Nicht-Unix-Betriebssysteme mit einem POSIX-Subsystem / einer POSIX-API (z. B. Microsoft Windows NT). Ich bin mir nicht sicher, ob diese Bedingungen ausreichen, um die Konsequenz daraus zu ziehen. Das chgrpoder chownkönnte Nebenwirkungen haben, die die Fähigkeit beeinträchtigen, das andere zu tun. Zum Beispiel nimmt chowndie Fähigkeit zu chgrp, das ist eine Tatsache. chgrplöscht das setuid / setgid-Bit, es kann irgendeine Form von ACL oder eine andere Form von Sicherheitskontext löschen ...
Stéphane Chazelas
@ StéphaneChazelas Wir sind uns einig, dass chowngefolgt von chgrpscheitern könnte, aber die Frage ist über chgrpgefolgt von chown. Hmmm, Sicherheitskontext ... könnte in einem System mit obligatorischer Zugriffskontrolle chgrpeine Datei verderben und sie nicht mehr chownierbar machen? Das scheint weit hergeholt.
Gilles 'SO- hör auf böse zu sein'
Vielleicht nicht weit hergeholt. Ich weiß nicht viel über NFSv4 / WinNT-ACLs, aber ich vermute, dass es dort etwas gibt, das solche Dinge möglich macht (und / oder Ihre dritte Annahme ungültig macht). Dennoch ist dieser Text ziemlich spezifisch und wer auch immer ihn schrieb, hätte ein spezifisches Beispiel im Sinn gehabt. Vielleicht wurde es von einigen Microsoft-Leuten geschrieben.
Stéphane Chazelas
Es ist Ihre letzte Änderung. Mit chown -R bob: students würde alice immer noch Suchberechtigungen verlieren dir, damit dies funktioniert, chownmü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.
Stéphane Chazelas
Die ungeprüfte Sekretariats-Fehltranskription und die rekursiven Randfall- chownTheorien scheinen sich zu widersprechen.
mikeserv