Erklärung zur chown(1) POSIX-Spezifikation

Question 1

DerMicrosoft Interix Unix-Subsystem (jetzt im Ruhestand)denn sein NT-Kernel behandelte Benutzer- und Gruppenberechtigungen etwas anders als einige andere:

Benutzer- und Gruppeninformationen werden gespeichert imSicherheit Access-Datenbank. Sowohl Benutzer als auch Gruppen werden in derselben Datenbank gespeichert, Gruppen- und Benutzernamen müssen jedoch eindeutig sein. Keine Gruppe kann den Namen eines Benutzernamens haben und umgekehrt.(Diese Datenbank ersetzt die /etc/passwdund /etc/groupsDateien in UNIX.)Benutzer und Gruppen werden mit der entsprechenden Windows-Methodik erstellt(Benutzer-Manager, Active Directory-Benutzer und -Computer oder Lokale Benutzer und Gruppen)oder mit dem Win32- net userBefehl.(Beispiel-Shellskripte zum Erstellen und Entfernen von Benutzern sind im Verzeichnis enthalten /usr/examples/admin.)Benutzer können vielen Gruppen angehören.

Hier sindmanchegenauere Handbuchauszüge:

Unter Windows kann ein Objekt entweder einem Benutzer oder einer Gruppe gehören. Unter UNIX ist dies anders, da dort ein Objekt nur einem Benutzer gehört.

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

Benutzer und Gruppen, die über die Berechtigung zum Zugriff auf ein Objekt verfügen, werden durch ihre SID identifiziert. Alle Objekte, die von Windows gesichert werden können, verfügen über eine DACL (Discretionary Access Control List), die aus einzelnen Einträgen besteht, die als Zugriffssteuerungseinträge (Access Control Entries, ACEs) bezeichnet werden. 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 Besitzer- und Gruppenoperanden sind beide optional; einer muss jedoch angegeben werden. Wenn der Gruppenoperand angegeben ist, muss ihm 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 von einem Prozess mit entsprechenden Berechtigungen geändert werden.

So wie ich es verstehe, bedeutet das, dass, wenn Ihr Benutzerkonto zu einer Windows-Gruppe gehört, die über ausreichende Berechtigungen verfügt, um die Berechtigungen einer Datei zu ändern, die dieser Gruppe gehört, es möglich ist, chgrpdiese Datei effektiv außerhalb der Kontrolle Ihres Benutzerkontos zu ändern. Dies bedeutet weniger Kontrolle, als Sie mit chownexpliziten user:groupParametern haben könnten. In diesem Kontext ohne die Möglichkeit,user: Und :groupSie könnten nie dieselben Ergebnisse erzielen wie sonst.

Hier ist ein Linkzu einem detaillierten Blick darauf, wie Interix mit Windows-ACLs interagiert, mit einem Schwerpunkt darauf, wie dieses Wissen auf Samba-Dateisysteme auf anderen Unix-Varianten anwendbar sein könnte.

Hier ist ein Linkzu einem JetztveraltetSolaris-Dokument mit einer Beschreibung des anpassbaren Elements, rstchowndas …

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

Wenn der Parameter auf den Wert 0... gesetzt ist, geschieht dies offensichtlich.

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

Eine solche Option macht Solaris nicht ungültigPOSIX-Konformität. Allein die Tatsache, dass es überhaupt eine Option ist, qualifiziert es alskonform:

Obwohl alle Implementierungen, die POSIX.1-2008 entsprechen, alle unten beschriebenen Funktionen unterstützen, kann essystem- oder dateisystemabhängige Konfigurationsprozeduren, die entfernen oder ändern können einige oder alle dieser Funktionen. Solche Konfigurationen sollten nicht vorgenommen werden, wenn 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 definiert ist, sollten Anwendungen die Funktionen sysconf(), pathconf(), oder fpathconf()oder das getconfDienstprogramm verwenden, um zu ermitteln, welche Funktionen zu diesem Zeitpunkt oder für den betreffenden Pfadnamen auf dem System vorhanden sind.

_POSIX_CHOWN_RESTRICTED

Die Verwendung von chown()ist auf einen Prozess mit entsprechenden Berechtigungen beschränkt und das Ändern der Gruppen-ID einer Datei ist nur auf die effektive Gruppen-ID des Prozesses oder auf eine seiner ergänzenden Gruppen-IDs möglich.

Die chown()Systemfunktion - das ist der dokumentierte Systemaufruf sowohl deschownUndchgrpShell-Dienstprogramme - istzum Scheitern verurteiltaus zahlreichen Gründen. Unter ihnen:

EACCES Für eine Komponente des Pfadpräfixes wurde die Suchberechtigung verweigert.

ELOOP Bei der Auflösung des Pfadarguments ist eine Schleife in den symbolischen Links aufgetreten.

EPERM Die effektive Benutzerkennung stimmt nicht mit dem Eigentümer der Datei überein oder der aufrufende Prozess verfügt nicht über die erforderlichen Berechtigungen und_POSIX_CHOWN_RESTRICTEDgibt an, dass dieses Privileg erforderlich ist.

Das Erteilen von Änderungsrechten an Nicht-Root-Benutzer war jedoch nie ein einzigartiges Verhalten unter Solaris. Es gibtsehr gut- wenn auch etwas veraltet - Abdeckung von Unix-Dateiberechtigungen indieser Forumsbeitragin dem der Autor feststellt:

Ursprünglich erlaubte Unix einem Dateibesitzer, eine Datei weiterzugeben. Der Besitzer einer Datei konnte den Besitzer auf jemand anderen ändern. Es gab für einen Nicht-Root-Benutzer keine Möglichkeit, diesen Vorgang rückgängig zu machen... BSD[später]chownvon Nicht-Root-Benutzern entfernt…[teilweise weil]…Es implementierte Datenträgerkontingente, die den Datenträgerspeicherplatz beschränken konnten, den ein Benutzer in einem Dateisystem haben konnte ... Unartige Benutzer konnten große Dateien preisgeben, um die Kontingente zu umgehen.

Heutzutage ist es nicht einfach zu sagen, ob ein Nicht-Root chowneine Datei öffnen kann. Viele Unix-Versionen erlaubenbeideVerhaltensweisen...

Ein weiterer guter - und neuerer -Mailinglisten-Beitragzitiert dies und fährt fort:

Bei den meisten Betriebssystemen ist standardmäßig chownnur Rootzugriff auf zulässig. Und es besteht Konsens darüber, dass dies aus Sicherheitsgründen so bleiben sollte. Wenn ein Nicht-Root-Benutzer den Besitzer einer Datei ändert und ein Ausführungsbit aktiviert ist, müssen die Bits SUIDund SGIDgelöscht werden. Dies kann bei passieren oder auch nicht root.

Ich denke, der letzte Absatz bringt es gut auf den Punkt.

In diesem Artikel wird auch CAP_CHOWNauf die Steuerung dieser Funktion unter Linux verwiesen.(das sollte nur das POSIX_CHOWN_RESTRICTEDVerhalten beeinflussen)Es besteht auch die CAP_FOWNERMöglichkeit, dass sich das Verhalten etwas anders verhält.

Und wieSie weisen darauf hin, im Jahr 2003:

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

...was von einem Konfigurationsparameter abhing setprivgroup.

In jedem Fall, in dem ein Nicht-Root-Benutzer Dateiberechtigungen manipulieren kann, ist es denkbar, wie in derBegründungIn Ihrer Frage wurde zitiert, dass ein Benutzer chowneine Datei, die ihm gehört, so ändern könnte, dass sie einem anderen Benutzer gehört. Wenn die Gruppeneigentümerschaft der Datei und die chownGruppen des betreffenden Benutzers nicht übereinstimmen, kann der Benutzer diese Datei nicht mehr ändern.

In diesem Szenariochown Dann chgrpwürde fehlschlagen, da der Benutzer nicht mehr berechtigt wäre, die Berechtigungen dieser Datei zu ändern, während chown user:group- solangeGruppegehört zum Benutzer - würde gelingen.

Es gibtwahrscheinlichzahlreiche andere Nischensituationen, die sich ähnlich ergeben könnten, darunter Verzeichnisklebrigund/odersetgidBits, Dateisystem- und/oder implementierungsspezifische Zugriffskontrolllisten.Dieser Threadist zum Beispiel interessant. Die unzähligen Permutationen gehen weit über mein eigenes schwaches Verständnis hinaus – weshalb diese Antwort wikied ist. Wenn Sie dies lesen, glauben Sie, dass es sich lohnt, es zu verbessern, und Sie glauben, Sie wissen, wie –Bitte.

Außerdem gibt es hier eine ausführliche Dokumentation zu den verschiedenen möglichen Auswirkungen von Dateiberechtigungen, Baumdurchquerung und symbolischen Links, die bei -Rekursiven chownAnwendungen zu einem ähnlichen Fehler führen können:

AusPOSIX XRATAbschnittsüberschriftenDritteUndVierte Domänen:

Im Allgemeinen möchten Benutzer, die die Option für eine Dateihierarchie-Durchquerung angeben, in einer einzigen physischen Hierarchie arbeiten, und daher werden symbolische Links, die auf Dateien außerhalb der Hierarchie verweisen können, ignoriert. Beispielsweise ist chown owner file eine andere Operation als der gleiche Befehl mit der angegebenen Option -R. In diesem Beispiel chown owner filewird das Verhalten des Befehls hier beschrieben, während das Verhalten des Befehlschown -RDie Eigentümerdatei wird in der dritten und vierten Domäne beschrieben.

...Es gibt ein Sicherheitsproblem bei der standardmäßigen Verwendung eines logischen Walks. Historisch gesehen hat der Befehlchown -RDie Benutzerdatei ist für den Superuser sicher, dasetuidUndsetgidBits gingen verloren, als der Dateieigentümer geändert wurde. Wenn der Durchlauf logisch wäre, wäre das Ändern des Eigentümers nicht mehr sicher, da ein Benutzer möglicherweise einen symbolischen Link eingefügt hat, der auf eine beliebige Datei im Baum zeigt. Dies würde wiederum das Hinzufügen einer Option zu den Befehlen erfordern, die Hierarchiedurchläufe durchführen, um nicht indirekt über die symbolischen Links zu gehen, und historische Skripte, die rekursive Durchläufe durchführen, würden sofort zu Sicherheitsproblemen. Obwohl dies hauptsächlich ein Problem für Systemadministratoren ist, ist es vorzuziehen, keine unterschiedlichen Standardeinstellungen für unterschiedliche Benutzerklassen zu haben.

...

In 4.3 BSD chgrpwurde während der Baumdurchquerung die Gruppe des symbolischen Links geändert, nicht das Ziel. Symbolische Links in 4.4 BSD hatten weder Besitzer, Gruppe, Modus noch andere standardmäßige UNIX-Systemdateiattribute.

Und vom POSIXchgrpAuf der eigentlichen Seite gibt es Folgendes, was auf eine mögliche unvollständige -Rekursive Aktion hinweist, oder zumindest auf das, wasgebrauchtzu sein:

Die System V- und BSD-Versionen verwenden unterschiedliche Exit-Statuscodes. Einige Implementierungen verwendeten den Exit-Status als Anzahl der aufgetretenen Fehler. Diese Vorgehensweise ist nicht praktikabel, da sie den Bereich gültiger Exit-Statuswerte überschreiten kann. Die Standardentwickler haben sich entschieden, diese zu maskieren, indem sie nur 0 und >0 als Exit-Werte angeben.

Answer

DerMicrosoft Interix Unix-Subsystem (jetzt im Ruhestand)denn sein NT-Kernel behandelte Benutzer- und Gruppenberechtigungen etwas anders als einige andere:

Benutzer- und Gruppeninformationen werden gespeichert imSicherheit Access-Datenbank. Sowohl Benutzer als auch Gruppen werden in derselben Datenbank gespeichert, Gruppen- und Benutzernamen müssen jedoch eindeutig sein. Keine Gruppe kann den Namen eines Benutzernamens haben und umgekehrt.(Diese Datenbank ersetzt die /etc/passwdund /etc/groupsDateien in UNIX.)Benutzer und Gruppen werden mit der entsprechenden Windows-Methodik erstellt(Benutzer-Manager, Active Directory-Benutzer und -Computer oder Lokale Benutzer und Gruppen)oder mit dem Win32- net userBefehl.(Beispiel-Shellskripte zum Erstellen und Entfernen von Benutzern sind im Verzeichnis enthalten /usr/examples/admin.)Benutzer können vielen Gruppen angehören.

Hier sindmanchegenauere Handbuchauszüge:

Unter Windows kann ein Objekt entweder einem Benutzer oder einer Gruppe gehören. Unter UNIX ist dies anders, da dort ein Objekt nur einem Benutzer gehört.

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

Benutzer und Gruppen, die über die Berechtigung zum Zugriff auf ein Objekt verfügen, werden durch ihre SID identifiziert. Alle Objekte, die von Windows gesichert werden können, verfügen über eine DACL (Discretionary Access Control List), die aus einzelnen Einträgen besteht, die als Zugriffssteuerungseinträge (Access Control Entries, ACEs) bezeichnet werden. 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 Besitzer- und Gruppenoperanden sind beide optional; einer muss jedoch angegeben werden. Wenn der Gruppenoperand angegeben ist, muss ihm 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 von einem Prozess mit entsprechenden Berechtigungen geändert werden.

So wie ich es verstehe, bedeutet das, dass, wenn Ihr Benutzerkonto zu einer Windows-Gruppe gehört, die über ausreichende Berechtigungen verfügt, um die Berechtigungen einer Datei zu ändern, die dieser Gruppe gehört, es möglich ist, chgrpdiese Datei effektiv außerhalb der Kontrolle Ihres Benutzerkontos zu ändern. Dies bedeutet weniger Kontrolle, als Sie mit chownexpliziten user:groupParametern haben könnten. In diesem Kontext ohne die Möglichkeit,user: Und :groupSie könnten nie dieselben Ergebnisse erzielen wie sonst.

Hier ist ein Linkzu einem detaillierten Blick darauf, wie Interix mit Windows-ACLs interagiert, mit einem Schwerpunkt darauf, wie dieses Wissen auf Samba-Dateisysteme auf anderen Unix-Varianten anwendbar sein könnte.

Hier ist ein Linkzu einem JetztveraltetSolaris-Dokument mit einer Beschreibung des anpassbaren Elements, rstchowndas …

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

Wenn der Parameter auf den Wert 0... gesetzt ist, geschieht dies offensichtlich.

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

Eine solche Option macht Solaris nicht ungültigPOSIX-Konformität. Allein die Tatsache, dass es überhaupt eine Option ist, qualifiziert es alskonform:

Obwohl alle Implementierungen, die POSIX.1-2008 entsprechen, alle unten beschriebenen Funktionen unterstützen, kann essystem- oder dateisystemabhängige Konfigurationsprozeduren, die entfernen oder ändern können einige oder alle dieser Funktionen. Solche Konfigurationen sollten nicht vorgenommen werden, wenn 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 definiert ist, sollten Anwendungen die Funktionen sysconf(), pathconf(), oder fpathconf()oder das getconfDienstprogramm verwenden, um zu ermitteln, welche Funktionen zu diesem Zeitpunkt oder für den betreffenden Pfadnamen auf dem System vorhanden sind.

_POSIX_CHOWN_RESTRICTED

Die Verwendung von chown()ist auf einen Prozess mit entsprechenden Berechtigungen beschränkt und das Ändern der Gruppen-ID einer Datei ist nur auf die effektive Gruppen-ID des Prozesses oder auf eine seiner ergänzenden Gruppen-IDs möglich.

Die chown()Systemfunktion - das ist der dokumentierte Systemaufruf sowohl deschownUndchgrpShell-Dienstprogramme - istzum Scheitern verurteiltaus zahlreichen Gründen. Unter ihnen:

EACCES Für eine Komponente des Pfadpräfixes wurde die Suchberechtigung verweigert.

ELOOP Bei der Auflösung des Pfadarguments ist eine Schleife in den symbolischen Links aufgetreten.

EPERM Die effektive Benutzerkennung stimmt nicht mit dem Eigentümer der Datei überein oder der aufrufende Prozess verfügt nicht über die erforderlichen Berechtigungen und_POSIX_CHOWN_RESTRICTEDgibt an, dass dieses Privileg erforderlich ist.

Das Erteilen von Änderungsrechten an Nicht-Root-Benutzer war jedoch nie ein einzigartiges Verhalten unter Solaris. Es gibtsehr gut- wenn auch etwas veraltet - Abdeckung von Unix-Dateiberechtigungen indieser Forumsbeitragin dem der Autor feststellt:

Ursprünglich erlaubte Unix einem Dateibesitzer, eine Datei weiterzugeben. Der Besitzer einer Datei konnte den Besitzer auf jemand anderen ändern. Es gab für einen Nicht-Root-Benutzer keine Möglichkeit, diesen Vorgang rückgängig zu machen... BSD[später]chownvon Nicht-Root-Benutzern entfernt…[teilweise weil]…Es implementierte Datenträgerkontingente, die den Datenträgerspeicherplatz beschränken konnten, den ein Benutzer in einem Dateisystem haben konnte ... Unartige Benutzer konnten große Dateien preisgeben, um die Kontingente zu umgehen.

Heutzutage ist es nicht einfach zu sagen, ob ein Nicht-Root chowneine Datei öffnen kann. Viele Unix-Versionen erlaubenbeideVerhaltensweisen...

Ein weiterer guter - und neuerer -Mailinglisten-Beitragzitiert dies und fährt fort:

Bei den meisten Betriebssystemen ist standardmäßig chownnur Rootzugriff auf zulässig. Und es besteht Konsens darüber, dass dies aus Sicherheitsgründen so bleiben sollte. Wenn ein Nicht-Root-Benutzer den Besitzer einer Datei ändert und ein Ausführungsbit aktiviert ist, müssen die Bits SUIDund SGIDgelöscht werden. Dies kann bei passieren oder auch nicht root.

Ich denke, der letzte Absatz bringt es gut auf den Punkt.

In diesem Artikel wird auch CAP_CHOWNauf die Steuerung dieser Funktion unter Linux verwiesen.(das sollte nur das POSIX_CHOWN_RESTRICTEDVerhalten beeinflussen)Es besteht auch die CAP_FOWNERMöglichkeit, dass sich das Verhalten etwas anders verhält.

Und wieSie weisen darauf hin, im Jahr 2003:

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

...was von einem Konfigurationsparameter abhing setprivgroup.

In jedem Fall, in dem ein Nicht-Root-Benutzer Dateiberechtigungen manipulieren kann, ist es denkbar, wie in derBegründungIn Ihrer Frage wurde zitiert, dass ein Benutzer chowneine Datei, die ihm gehört, so ändern könnte, dass sie einem anderen Benutzer gehört. Wenn die Gruppeneigentümerschaft der Datei und die chownGruppen des betreffenden Benutzers nicht übereinstimmen, kann der Benutzer diese Datei nicht mehr ändern.

In diesem Szenariochown Dann chgrpwürde fehlschlagen, da der Benutzer nicht mehr berechtigt wäre, die Berechtigungen dieser Datei zu ändern, während chown user:group- solangeGruppegehört zum Benutzer - würde gelingen.

Es gibtwahrscheinlichzahlreiche andere Nischensituationen, die sich ähnlich ergeben könnten, darunter Verzeichnisklebrigund/odersetgidBits, Dateisystem- und/oder implementierungsspezifische Zugriffskontrolllisten.Dieser Threadist zum Beispiel interessant. Die unzähligen Permutationen gehen weit über mein eigenes schwaches Verständnis hinaus – weshalb diese Antwort wikied ist. Wenn Sie dies lesen, glauben Sie, dass es sich lohnt, es zu verbessern, und Sie glauben, Sie wissen, wie –Bitte.

Außerdem gibt es hier eine ausführliche Dokumentation zu den verschiedenen möglichen Auswirkungen von Dateiberechtigungen, Baumdurchquerung und symbolischen Links, die bei -Rekursiven chownAnwendungen zu einem ähnlichen Fehler führen können:

AusPOSIX XRATAbschnittsüberschriftenDritteUndVierte Domänen:

Im Allgemeinen möchten Benutzer, die die Option für eine Dateihierarchie-Durchquerung angeben, in einer einzigen physischen Hierarchie arbeiten, und daher werden symbolische Links, die auf Dateien außerhalb der Hierarchie verweisen können, ignoriert. Beispielsweise ist chown owner file eine andere Operation als der gleiche Befehl mit der angegebenen Option -R. In diesem Beispiel chown owner filewird das Verhalten des Befehls hier beschrieben, während das Verhalten des Befehlschown -RDie Eigentümerdatei wird in der dritten und vierten Domäne beschrieben.

...Es gibt ein Sicherheitsproblem bei der standardmäßigen Verwendung eines logischen Walks. Historisch gesehen hat der Befehlchown -RDie Benutzerdatei ist für den Superuser sicher, dasetuidUndsetgidBits gingen verloren, als der Dateieigentümer geändert wurde. Wenn der Durchlauf logisch wäre, wäre das Ändern des Eigentümers nicht mehr sicher, da ein Benutzer möglicherweise einen symbolischen Link eingefügt hat, der auf eine beliebige Datei im Baum zeigt. Dies würde wiederum das Hinzufügen einer Option zu den Befehlen erfordern, die Hierarchiedurchläufe durchführen, um nicht indirekt über die symbolischen Links zu gehen, und historische Skripte, die rekursive Durchläufe durchführen, würden sofort zu Sicherheitsproblemen. Obwohl dies hauptsächlich ein Problem für Systemadministratoren ist, ist es vorzuziehen, keine unterschiedlichen Standardeinstellungen für unterschiedliche Benutzerklassen zu haben.

...

In 4.3 BSD chgrpwurde während der Baumdurchquerung die Gruppe des symbolischen Links geändert, nicht das Ziel. Symbolische Links in 4.4 BSD hatten weder Besitzer, Gruppe, Modus noch andere standardmäßige UNIX-Systemdateiattribute.

Und vom POSIXchgrpAuf der eigentlichen Seite gibt es Folgendes, was auf eine mögliche unvollständige -Rekursive Aktion hinweist, oder zumindest auf das, wasgebrauchtzu sein:

Die System V- und BSD-Versionen verwenden unterschiedliche Exit-Statuscodes. Einige Implementierungen verwendeten den Exit-Status als Anzahl der aufgetretenen Fehler. Diese Vorgehensweise ist nicht praktikabel, da sie den Bereich gültiger Exit-Statuswerte überschreiten kann. Die Standardentwickler haben sich entschieden, diese zu maskieren, indem sie nur 0 und >0 als Exit-Werte angeben.

Question 2

Annahme 1: Die Regeln zur Bestimmung, ob chownerfolgreich ist, prüfen die Zielbenutzer- und -gruppenteile unabhängig voneinander, d. h. 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 zur Bestimmung, ob chownein Erfolg eintritt, hängen nicht davon ab, zu welcher Gruppe die Datei aktuell gehört.

Schlussfolgerung: Wenn chown(file, uid, gid)erfolgreich wäre, dann wäre auch erfolgreich chown(file, -1, gid) && chown(file, uid, -1).

Mir ist keine Unix-Variante bekannt, die eine dieser Annahmen verletzen würde, sie scheinen ziemlich sicher.

Dieser Satz klingt wie etwas, das jemand im Komitee gesagt hat, als er müde war, nachdem er stundenlang darüber diskutiert hatte, wie viele Optionen in den Kopf eines psAufrufs passen – oder wie etwas, das die Sekretärin falsch transkribiert hat – und das niemandem bei der Überprüfung aufgefallen ist. Schließlich gibt es andere, gute Gründe, die automatische Änderung von Benutzer und Gruppe zuzulassen, darunter den Leistungsgrund, der auch in der POSIX-Begründung genannt wird, sowie die Atomizität (ach, wenn es doch nur einen einzigen Aufruf zum Ändern von Eigentümerschaft und Berechtigungen gäbe).

Ein Fall, in dem Annahme 3 falsch sein könnte, ist ein System, in dem ein Prozess die Möglichkeit erhält, Dateibesitzer zu ändern, aber nur, wenn er Schreibberechtigung für die Datei hat. Obwohl das einigermaßen realistisch ist, kenne ich kein System, in dem dies der Fall ist. Dann chgrpkönnte eine Gruppe aus einem Prozess, der weder als Root noch als Benutzer, dem die Datei gehört, läuft, die Datei für einen späteren Zeitpunkt sperren chown.

Bei einem rekursiven Aufruf gibt es Grenzfälle, in denen ein ganzer Durchlauf von chgrpgefolgt von einem ganzen Durchlauf chownvon fehlschlagen kann, wenn ein einzelner Durchlauf erfolgreich wäre. Dies ist kein sehr überzeugendes Argument, da es sich um Verzeichnisse handelt, für deren Durchlauf der Eigentümer keine Berechtigung hat, und eine Anwendung, die sich vor allen solchen Fällen schützen möchte, ohnehin mit den Berechtigungen herumspielen müsste. Dennoch erfüllt es technisch die Bedingung dieser Begründung. Nehmen wir an, dass der laufende Prozess über einen effektiven Benutzer alice, eine effektive Gruppe staffund die Fähigkeit verfügt, Dateieigentümer beliebig zu ändern (nicht nur, um sie preiszugeben; mehrere Unix-Varianten haben eine solche Fähigkeit, obwohl sie selten Nicht-Root-Prozessen gewährt wird).

$ 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

Answer

Annahme 1: Die Regeln zur Bestimmung, ob chownerfolgreich ist, prüfen die Zielbenutzer- und -gruppenteile unabhängig voneinander, d. h. 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 zur Bestimmung, ob chownein Erfolg eintritt, hängen nicht davon ab, zu welcher Gruppe die Datei aktuell gehört.

Schlussfolgerung: Wenn chown(file, uid, gid)erfolgreich wäre, dann wäre auch erfolgreich chown(file, -1, gid) && chown(file, uid, -1).

Mir ist keine Unix-Variante bekannt, die eine dieser Annahmen verletzen würde, sie scheinen ziemlich sicher.

Dieser Satz klingt wie etwas, das jemand im Komitee gesagt hat, als er müde war, nachdem er stundenlang darüber diskutiert hatte, wie viele Optionen in den Kopf eines psAufrufs passen – oder wie etwas, das die Sekretärin falsch transkribiert hat – und das niemandem bei der Überprüfung aufgefallen ist. Schließlich gibt es andere, gute Gründe, die automatische Änderung von Benutzer und Gruppe zuzulassen, darunter den Leistungsgrund, der auch in der POSIX-Begründung genannt wird, sowie die Atomizität (ach, wenn es doch nur einen einzigen Aufruf zum Ändern von Eigentümerschaft und Berechtigungen gäbe).

Ein Fall, in dem Annahme 3 falsch sein könnte, ist ein System, in dem ein Prozess die Möglichkeit erhält, Dateibesitzer zu ändern, aber nur, wenn er Schreibberechtigung für die Datei hat. Obwohl das einigermaßen realistisch ist, kenne ich kein System, in dem dies der Fall ist. Dann chgrpkönnte eine Gruppe aus einem Prozess, der weder als Root noch als Benutzer, dem die Datei gehört, läuft, die Datei für einen späteren Zeitpunkt sperren chown.

Bei einem rekursiven Aufruf gibt es Grenzfälle, in denen ein ganzer Durchlauf von chgrpgefolgt von einem ganzen Durchlauf chownvon fehlschlagen kann, wenn ein einzelner Durchlauf erfolgreich wäre. Dies ist kein sehr überzeugendes Argument, da es sich um Verzeichnisse handelt, für deren Durchlauf der Eigentümer keine Berechtigung hat, und eine Anwendung, die sich vor allen solchen Fällen schützen möchte, ohnehin mit den Berechtigungen herumspielen müsste. Dennoch erfüllt es technisch die Bedingung dieser Begründung. Nehmen wir an, dass der laufende Prozess über einen effektiven Benutzer alice, eine effektive Gruppe staffund die Fähigkeit verfügt, Dateieigentümer beliebig zu ändern (nicht nur, um sie preiszugeben; mehrere Unix-Varianten haben eine solche Fähigkeit, obwohl sie selten Nicht-Root-Prozessen gewährt wird).

$ 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

Erklärung zur chown(1) POSIX-Spezifikation

Antwort1

Antwort2

verwandte Informationen