Gibt es einen Grund, warum Inhaberrechte bestehen? Reichen die Gruppenrechte nicht aus?

Ich denke, ich verstehe eher, wie Dateiberechtigungen unter Linux funktionieren. Ich verstehe jedoch nicht wirklich, warum sie in drei Ebenen unterteilt sind und nicht in zwei.

Ich hätte gerne die folgenden Fragen beantwortet:

• Ist das bewusstes Design oder ein Patch? Das heißt: Wurden die Berechtigungen des Eigentümers / der Gruppe zusammen mit einer Begründung entworfen und erstellt, oder kamen sie nacheinander, um eine Anforderung zu beantworten?
• Gibt es ein Szenario, in dem der Benutzer / die Gruppe / das andere Schema nützlich ist, ein Gruppen- / anderes Schema jedoch nicht ausreicht?

Bei Antworten auf die erste Frage sollten entweder Lehrbücher oder offizielle Diskussionsrunden zitiert werden.

Von mir berücksichtigte Anwendungsfälle sind:

• Private Dateien - sehr einfach zu erhalten, indem eine Gruppe pro Benutzer erstellt wird, was in vielen Systemen häufig der Fall ist.
• Erlauben, dass nur der Eigentümer (z. B. der Systemdienst) in eine Datei schreibt, dass nur eine bestimmte Gruppe lesen und allen anderen Zugriff verweigern kann - das Problem bei diesem Beispiel ist, dass der Benutzer , sobald eine Gruppe Schreibzugriff haben muss, der Benutzer ist / group / other schlägt damit fehl. Die Antwort für beide ist die Verwendung von ACLs und rechtfertigt IMHO nicht das Vorhandensein von Eigentümerberechtigungen.

NB Ich habe diese Frage verfeinert, nachdem die Frage in superuser.com geschlossen wurde .

BEARBEITEN korrigiert, "aber ein Gruppen / Eigentümer-Schema wird nicht ausreichen", um "... Gruppe / andere ...".

Geschichte

Ursprünglich hatte Unix nur Berechtigungen für den Eigentümer und für andere Benutzer: Es gab keine Gruppen. Siehe insbesondere die Dokumentation zu Unix Version 1 chmod(1). Für die Abwärtskompatibilität sind Berechtigungen für den besitzenden Benutzer erforderlich.

Gruppen kamen später. ACLs, mit denen mehr als eine Gruppe in die Berechtigungen einer Datei einbezogen werden kann, wurden erst viel später erstellt.

Ausdruckskraft

Mit drei Berechtigungen für eine Datei können Sie detailliertere Berechtigungen als mit nur zwei Berechtigungen zu einem sehr niedrigen Preis (viel niedriger als ACLs) erwerben. Eine Datei kann beispielsweise den folgenden Modus haben rw-r-----: Nur für den Benutzer beschreibbar, für eine Gruppe lesbar.

Ein weiterer Anwendungsfall sind ausführbare setuid-Dateien, die nur von einer Gruppe ausgeführt werden können. Beispielsweise erlaubt ein Programm mit dem Modus, dessen rwsr-x---Eigentümer root:admines ist, nur Benutzern in der adminGruppe, dieses Programm als Root auszuführen.

"Es gibt Berechtigungen, die dieses Schema nicht ausdrücken kann", ist ein schreckliches Argument dagegen. Das anwendbare Kriterium ist, gibt es genug übliche Fälle, die die Kosten rechtfertigen? In diesem Fall sind die Kosten minimal, insbesondere in Anbetracht der anderen Gründe für den Benutzer / die Gruppe / das andere Triptychon.

Einfachheit

Eine Gruppe pro Benutzer hat einen kleinen, aber nicht unerheblichen Verwaltungsaufwand. Es ist gut, dass der extrem häufige Fall einer privaten Datei nicht davon abhängt. Eine Anwendung, die eine private Datei erstellt (z. B. ein E-Mail-Übermittlungsprogramm), muss der Datei lediglich den Modus 600 zuweisen. Sie muss nicht die Gruppendatenbank durchsuchen, um nach der Gruppe zu suchen, die nur den Benutzer und enthält Was tun, wenn es keine oder mehrere solche Gruppen gibt?

Wenn Sie aus einer anderen Richtung kommen, nehmen Sie an, Sie sehen eine Datei und möchten ihre Berechtigungen prüfen (dh prüfen, ob sie so sind, wie sie sein sollten). Es ist viel einfacher, wenn Sie "nur für den Benutzer verfügbar, in Ordnung, als nächstes" gehen können, als wenn Sie Gruppendefinitionen nachverfolgen müssen. (Diese Komplexität ist das Problem von Systemen, die erweiterte Funktionen wie ACLs oder Funktionen in hohem Maße nutzen.)

Orthogonalität

Jeder Prozess führt Dateisystemzugriffe als ein bestimmter Benutzer und eine bestimmte Gruppe durch (mit komplizierteren Regeln für moderne Unices, die zusätzliche Gruppen unterstützen). Der Benutzer wird für eine Vielzahl von Dingen verwendet, einschließlich des Testens auf root (UID 0) und der Erlaubnis zur Signalübermittlung (benutzerbasiert). Es besteht eine natürliche Symmetrie zwischen der Unterscheidung von Benutzern und Gruppen in Prozessberechtigungen und der Unterscheidung von Benutzern und Gruppen in Dateisystemberechtigungen.

Ist das bewusstes Design oder ein Patch? Das heißt: Wurden die Berechtigungen des Eigentümers / der Gruppe zusammen mit einer Begründung entworfen und erstellt, oder kamen sie nacheinander, um eine Anforderung zu beantworten?

Die Benutzer- / Gruppen- / sonstigen Berechtigungen für eine Datei sind Teil des ursprünglichen Unix-Designs.

Gibt es ein Szenario, in dem das Benutzer- / Gruppen- / andere Schema nützlich ist, ein Gruppen- / Besitzerschema jedoch nicht ausreicht?

Ja, praktisch jedes Szenario, in dem Sicherheit und Zugangskontrolle wichtig sind.

Beispiel: Möglicherweise möchten Sie einigen Binärdateien / Skripten auf einem System nur Ausführungszugriff gewähren otherund den Lese- / Schreibzugriff auf beschränken root.

Ich bin mir nicht sicher, was Sie bei einem Dateisystem-Berechtigungsmodell denken, das nur Eigentümer- / Gruppenberechtigungen hat. Ich weiß nicht, wie Sie ein sicheres Betriebssystem ohne die Existenz einer otherKategorie haben könnten .

EDIT: Angenommen, Sie group/othermeinen, dass hier nur Berechtigungen erforderlich sind, dann schlage ich vor, eine Möglichkeit zum Verwalten von kryptografischen Schlüsseln oder eine Möglichkeit zu entwickeln, mit der nur die richtigen Benutzer auf ihren Mail-Spool zugreifen können. Es gibt Fälle, in denen ein privater Schlüssel möglicherweise nur user:userEigentum sein darf , in anderen Fällen ist es jedoch sinnvoll, ihm das user:groupEigentum zu geben .

Private Dateien - sehr einfach zu erhalten, indem eine Gruppe pro Benutzer erstellt wird, was in vielen Systemen häufig der Fall ist.

Zugegeben, das ist einfach, aber genauso einfach, wenn eine otherGruppe existiert ...

Erlauben, dass nur der Eigentümer (z. B. der Systemdienst) in eine Datei schreibt, dass nur eine bestimmte Gruppe lesen und allen anderen Zugriff verweigern kann - das Problem bei diesem Beispiel ist, dass der Benutzer, sobald eine Gruppe Schreibzugriff haben muss, der Benutzer ist / group / other schlägt damit fehl. Die Antwort für beide ist die Verwendung von ACLs und rechtfertigt IMHO nicht das Vorhandensein von Eigentümerberechtigungen.

Ich habe den Teil Ihrer Aussage hervorgehoben, der meinen Standpunkt über die logische Notwendigkeit einer otherKategorie in Unix-Dateisystemberechtigungen zu wiederholen scheint .

Solch ein Dateisystemdesign, wie Sie es sich vorstellen (soweit ich das beurteilen kann), wäre entweder unsicher oder unhandlich. Unix wurde von einigen sehr intelligenten Leuten entwickelt, und ich denke, dass ihr Modell das bestmögliche Gleichgewicht zwischen Sicherheit und Flexibilität bietet.

Ist das bewusstes Design oder ein Patch? Das heißt: Wurden die Berechtigungen des Eigentümers / der Gruppe zusammen mit einer Begründung entworfen und erstellt, oder kamen sie nacheinander, um eine Anforderung zu beantworten?

Ja, dies ist ein absichtliches Design, das in UNIX seit den Anfängen vorhanden ist. Es wurde auf Systemen implementiert, bei denen der Arbeitsspeicher in KB gemessen wurde und die CPUs nach heutigen Maßstäben extrem langsam waren. Größe und Geschwindigkeit solcher Suchvorgänge waren wichtig. ACLs hätten mehr Speicherplatz benötigt und wären langsamer gewesen. Funktionell wird die everyoneGruppe durch die anderen Sicherheitsflags dargestellt.

Gibt es ein Szenario, in dem das Benutzer- / Gruppen- / andere Schema nützlich ist, ein Gruppen- / Besitzerschema jedoch nicht ausreicht?

Die Berechtigungen, die ich normalerweise für den Dateizugriff verwende, sind: (Ich verwende Bitwerte aus Gründen der Einfachheit und weil ich sie normalerweise so einstelle.)

• 600oder 400: Nur Benutzerzugriff (und ja, ich erteile dem Benutzer nur Lesezugriff).
• 640oder 660: Benutzer- und Gruppenzugriff.
• 644, 666oder 664: Benutzer, Gruppe und anderer Zugriff. Jedes Zwei-Ebenen-Berechtigungsschema kann nur zwei dieser drei Fälle behandeln. Die dritte würde ACLs erfordern.

Für Verzeichnisse und Programme verwende ich üblicherweise:

• 700oder 500: Nur Benutzerzugriff
• 750oder 710: Zugriff nur für Gruppen
• 755, 777, 775, Oder 751: Benutzer, Gruppen und anderer Zugang. Es gelten die gleichen Kommentare wie für Dateien.

Die oben genannten sind die am häufigsten verwendeten, aber keine vollständige Liste der von mir verwendeten Berechtigungseinstellungen. Die oben genannten Berechtigungen in Kombination mit einer Gruppe (manchmal mit einem klebrigen Gruppenbit in Verzeichnissen) haben in allen Fällen genügt, in denen ich möglicherweise eine ACL verwendet habe.

Wie oben erwähnt, ist es sehr einfach, die Berechtigung in einer Verzeichnisliste aufzulisten. Wenn keine ACLs verwendet werden, kann ich Zugriffsberechtigungen nur mit einer Verzeichnisliste überwachen. Wenn ich mit ACL-basierten Systemen arbeite, finde ich es sehr schwierig, Berechtigungen zu überprüfen oder zu überwachen.

Das Benutzer- / Gruppen- / andere Berechtigungssystem wurde entwickelt, bevor ACLs erfunden wurden. Es geht auf die Anfänge von UNIX zurück, daher kann man nicht sagen, dass das Problem mit ACLs gelöst werden sollte. Selbst wenn das Konzept einer ACL offensichtlich erscheint, wäre ein erheblicher zusätzlicher Aufwand erforderlich gewesen, um eine variable Menge an Berechtigungsinformationen für jede Datei zu speichern und zu verwalten, anstatt eine feste Menge.

Die Verwendung von ACLs für alles bedeutet auch, dass Sie nicht über eine genau definierte Teilmenge der Berechtigungsinformationen verfügen, die "auf einen Blick" angezeigt werden können. Die Ausgabe für ls -lzeigt die Standardberechtigungen (Benutzer / Gruppe / Andere), den Namen des Benutzers und der Gruppe sowie eine zusätzliche Notation (z. B. +oder ein @Zeichen) für Einträge, denen eine ACL zugeordnet ist, in einer Zeile an. Ihr System würde es erfordern, die "oberen zwei" Gruppen in der ACL zu identifizieren, um äquivalente Funktionalität bereitzustellen.

Als weiterer Punkt muss eine Datei noch hat einen Besitzer in dem UNIX - Modell , weil UNIX ACLs nicht für zur Verfügung stellt , die es erlaubt ist , die ACL zu ändern.