Ich bin auf einen alten, aber sehr interessanten Vorschlag von Neil Brown aus dem Jahr 2002 gestoßen: Dateisysteme sollten keine Benutzerkennungen und Rechte beinhalten, sich also ähnlich zu vfat verhalten, und die Zugriffsbeschränkung sollte über einen Dienst im Userspace erfolgen.
Der Vorschlag trifft zwei entscheidende Punkte: 95 % der Anforderungen an Benutzerrechte fallen in eine der beiden Gruppen (1) »völlig trivial« oder (2) »sehr speziell« – dazwischen liegt selten etwas. Für den überwiegenden Teil der Dateien in / und /usr ist es unerheblich, wem diese gehören, und alle Dateien in /home sollten dem einen Benutzer gehören. Lese- und Schreibrechte lassen sich auch für komplette Dateisystemsegmente regeln, sprich für einen Benutzer ist alles bis auf sein Verzeichnis schreibgeschützt.
Beim Austausch von Datenträgern mit anderen Systemen haben sich auch rechtelose Dateisysteme wie ISO9660 bei CDs oder FAT bei USB-Sticks und Digitalkameras als Vorteil erwiesen, da Benutzerkennungen vom Computer abhängen und bei physischem Zugriff auf ein Gerät die Rechte eh bedeutungslos sind.
Mittlerweile gibt es bind-mounts, über die entsprechende Teile des Dateisystems beim Login zusammengesetzt werden können, so dass das Benutzerverzeichnis wirklich /home ist und darin auch die temporären Dateien aus /tmp liegen. Durch die Mount-Namespaces kann jeder Prozess bzw. eine Gruppe von Prozessen ihre eigene Verzeichnishierarchie haben, in die zum Beispiel auch Verzeichnisse zum Dateiaustausch eingeblendet werden.
Alle Rechte, die komplizierter sind, sind meist so kompliziert, dass sie sich auch mit den POSIX-ACLs nicht zufriedenstellend ausdrücken lassen bzw. dahin, dass es nur einen Eigentümer gibt, der Dateirechte ändern kann. Für Verzeichnisse wäre es hilfreich, wenn man das Erstellen von Dateien erlauben, aber das Löschen verhindern könnte. Bei einigen Dateien sollte ein Anhängen (öffnen mit O_APPEND) erlaubt sein, aber kein beliebiges Schreiben in der Datei.
Wenn diese Regeln in einer Datei gespeichert wären (das Journal bei ext4 ist auch nur eine nicht sichtbare Datei), könnten sie von dem Dienst geladen und entsprechend angewandt werden. Auf diesem Wege könnte man auch wesentlich kompliziertere Regeln umsetzen, als es die üblichen Unixrechte oder ACLs ermöglichen. Vorstellbar ist auch, dass temporäre Regeln generiert werden.
Seit 2002 hat sich ja vieles am Kernel verändert und heute gibt es unter anderem Linux Security Modules, die neben den Unixrechten den Dateizugriff steuern. Dann gibt es fuse, worüber heute praktisch bereits ein solches Zugriffsrechtesystem umgesetzt werden kann. Oder mit der Kernel-internen virtuellen Maschine BPF ließen sich die Regeln auch als Code umsetzen. Und am Horizont zieht io_uring als performante Kommunikation zwischen Kernel- und Userspace auf, womit die Verluste von Kontextwechseln verschwinden und somit tatsächlich ein Userspace-Prozess die Entscheidung über den Zugriff übernehmen kann.
Aber der Kernel ist vielleicht gar nicht das Problem. Die größten Änderungen wären für Dienste und Benutzerprogramme notwendig. Angefangen natürlich von Programmen wie ls und chmod, aber auch anderen Programmen, die davon leben, dass sie überall hinkommen. Die Frage nach den Zugriffsrechten oder Änderungswünsche müssten sie dann an einen Benutzerprozess (per D-Bus) richten.
Und dann sind da noch die Benutzer: Ein wahrer Aufschrei würde durch die Lande ziehen, wenn man Benutzerrechte »abschaffen« wollte. Und noch schlimmer würde es werden, wenn man sie gegen ein Regelwerk ähnlich dem htaccess vom Apachen ersetzen würde.
Ich sehe wahrlich einige Erleichterungen vor allem für Anfänger und mehr Möglichkeiten für Experten mit einem solchen System. Vielleicht kommt es ja noch irgendwann, aber die Eingriffe in die Dateisysteme, die Änderungen der Kernel-API (creat(2), statx(2), setfsuid(2) u. s. w.) und damit einhergehend der Bruch mit POSIX und die Änderung der Denkweise der Nutzer machen dies unwahrscheinlich.
Eine echt gute Idee, die Neil Brown da vor 18 Jahren geäußert hat. Sein Einwand von damals hat auf alle Fälle eine Berechtigung: »Ein Problem daran, wenn eine gute, aber nicht die beste Lösung akzeptiert wird, ist, dass die Bereitschaft, die beste Lösung zu finden, zurückgeht.« (»a problem with including something that is 'good' but might not be 'best' is that it reduced the incentive to create the 'best' thing«)
Weiteres
- Michael Orlitzky { There was an attempt to save Linux filesystem ACLs }
- Mit AppArmor entsteht zum Teil schon eine solche Auslagerung der Rechte aus dem Dateisystem, während SELinux immer noch die Einbettung der Informationen in das Dateisystem vornimmt, aber eben über das LSM werden die Entscheidungen für den Zugriff aus dem Dateisystem ausgelagert.