Gibt es einen Grund, warum "Besitzer"-Berechtigungen vorhanden sind? Reichen Gruppenberechtigungen nicht aus?

Geschichte

Ursprünglich hatte Unix nur Berechtigungen für den besitzenden Benutzer und für andere Benutzer:es gab keine Gruppen. Siehe die Dokumentation von Unix Version 1, insbesondere chmod(1) . Abwärtskompatibilität erfordert also nicht zuletzt Berechtigungen für den besitzenden Benutzer.

Gruppen kamen später. ACLs, die es erlaubten, mehr als eine Gruppe in die Berechtigungen einer Datei einzubeziehen, kamen viel später.

Ausdruckskraft

Drei Berechtigungen für eine Datei ermöglichen feinkörnigere Berechtigungen als nur zwei, und das zu sehr geringen Kosten (viel niedriger als ACLs). Beispielsweise kann eine Datei den Modus rw-r----- haben :nur vom besitzenden Benutzer beschreibbar, von einer Gruppe lesbar.

Ein weiterer Anwendungsfall sind ausführbare setuid-Dateien, die nur von einer Gruppe ausführbar sind. Zum Beispiel ein Programm mit Modus rwsr-x--- im Besitz von root:admin erlaubt nur Benutzern im admin Gruppe, um 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 genügend gemeinsame aussagekräftige Fälle, die die Kosten rechtfertigen? In diesem Fall sind die Kosten minimal, insbesondere angesichts der anderen Gründe für das Benutzer-/Gruppen-/andere Triptychon.

Einfachheit

Eine Gruppe pro Benutzer zu haben, hat einen kleinen, aber nicht unerheblichen Verwaltungsaufwand. Gut, dass der extrem häufige Fall einer privaten Datei davon nicht abhängt. Eine Anwendung, die eine private Datei erstellt (z. B. ein E-Mail-Versandprogramm), weiß, dass sie der Datei nur den Modus 600 geben muss. Sie muss nicht die Gruppendatenbank durchsuchen, um nach der Gruppe zu suchen, die nur den Benutzer enthält – und was tun, wenn es keine solche Gruppe oder mehr als eine gibt?

Wenn Sie aus einer anderen Richtung kommen, nehmen Sie an, Sie sehen eine Datei und möchten ihre Berechtigungen prüfen (d. h. überprüfen, ob sie so sind, wie sie sein sollten). Es ist viel einfacher, wenn Sie „nur für den Benutzer zugänglich, fein, weiter“ gehen können, als wenn Sie Gruppendefinitionen nachverfolgen müssen. (Eine solche Komplexität ist der Fluch von Systemen, die fortgeschrittene Funktionen wie ACLs oder Fähigkeiten stark 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 viele Dinge verwendet, darunter das Testen auf Root (uid 0) und die Berechtigung 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 absichtliches Design oder ein Patch? Das heißt – wurden die Eigentümer-/Gruppenberechtigungen zusammen mit einer bestimmten Begründung entworfen und erstellt, oder kamen sie nacheinander, um einen Bedarf zu decken?

Die Benutzer-/Gruppen-/anderen 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, aber ein Gruppen-/Besitzer-Schema nicht ausreicht?

Ja, praktisch jedes Szenario, das ich mir vorstellen kann, wo Sicherheit und Zugangskontrolle wichtig sind.

Beispiel:Sie möchten einigen Binärdateien/Skripten auf einem System nur Ausführungszugriff auf other geben , und beschränken Sie den Lese-/Schreibzugriff auf root .

Ich bin mir nicht sicher, was Sie für ein Dateisystem-Berechtigungsmodell im Sinn haben, das nur Besitzer-/Gruppenberechtigungen hat. Ich weiß nicht, wie Sie ein sicheres Betriebssystem ohne die Existenz eines other haben könnten Kategorie.

BEARBEITEN: Angenommen, Sie meinen hier group/other Berechtigungen sind alles, was benötigt würde, dann schlage ich vor, einen Weg zu finden, um kryptografische Schlüssel zu verwalten, oder einen Weg, dass nur die richtigen Benutzer auf ihre Mail-Spool zugreifen können. Es gibt Fälle, in denen ein privater Schlüssel unbedingt user:user benötigt Eigentum, aber andere Fälle, in denen es sinnvoll ist, ihm user:group zu geben Eigentum.

private Dateien - sehr leicht erhältlich, indem man eine Gruppe pro Benutzer erstellt, was oft so gemacht wird, wie es in vielen Systemen der Fall ist.

Zugegeben, das ist einfach, aber es ist genauso einfach, wenn ein other vorhanden ist Gruppe...

nur dem Eigentümer (z. B. Systemdienst) erlauben, in eine Datei zu schreiben, nur einer bestimmten Gruppe das Lesen zu erlauben und alle anderen Zugriffe zu verweigern - Das Problem bei diesem Beispiel besteht darin, dass der Benutzer/die Gruppe/andere damit fehlschlägt, sobald eine Gruppe Schreibzugriff haben muss. Die Antwort für beide ist die Verwendung von ACLs und rechtfertigt meiner Meinung nach nicht die Existenz von Besitzerberechtigungen.

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

Ein solches Dateisystemdesign, wie Sie es zu erwägen scheinen (soweit ich das beurteilen kann), wäre entweder unsicher oder unhandlich. Unix wurde von einigen sehr klugen Leuten entwickelt, und ich denke, ihr Modell bietet die bestmögliche Balance zwischen Sicherheit und Flexibilität.

Ist das absichtliches Design oder ein Patch? Das heißt - wurden die Eigentümer-/Gruppenberechtigungen zusammen mit einer bestimmten Begründung entworfen und erstellt oder kamen sie nacheinander, um ein Bedürfnis zu erfüllen?

Ja, dies ist ein bewusstes Design, das in UNIX seit den Anfängen vorhanden ist. Es wurde auf Systemen implementiert, auf denen der Speicher in KB gemessen wurde und die CPUs nach heutigen Maßstäben extrem langsam waren. Größe und Geschwindigkeit solcher Suchen waren wichtig. ACLs hätten mehr Speicherplatz benötigt und wären langsamer gewesen. Funktional die everyone Gruppe wird durch die anderen Sicherheitsflags repräsentiert.

Gibt es ein Szenario, in dem das Benutzer-/Gruppen-/Andere-Schema nützlich ist, aber ein Gruppen-/Besitzer-Schema nicht ausreicht?

Berechtigungen, die ich üblicherweise für den Dateizugriff verwende, sind:(Ich verwende der Einfachheit halber Bitwerte und weil ich sie normalerweise so setze.)

• 600 oder 400 :Nur Benutzerzugriff (und ja, ich gewähre dem Benutzer nur Lesezugriff).
• 640 oder 660 :Benutzer- und Gruppenzugriff.
• 644 , 666 oder 664 :Benutzer-, Gruppen- und sonstiger Zugriff. Jedes Berechtigungsschema mit zwei Ebenen kann nur zwei dieser drei Fälle behandeln. Der dritte würde ACLs erfordern.

Für Verzeichnisse und Programme, die ich häufig verwende:

• 700 oder 500 :Nur Benutzerzugriff
• 750 oder 710 :Nur Gruppenzugriff
• 755 , 777 , 775 , oder 751 :Benutzer-, Gruppen- und sonstiger Zugriff. 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 Sticky-Group-Bit für Verzeichnisse) haben in allen Fällen ausgereicht, in denen ich möglicherweise eine ACL verwendet habe.

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