Erklärung zu chown (1) POSIX spec

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?

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.

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