Zusammenfassung

  • draft-ietf-nfsv4-posix-acls-02 schlägt vier optionale Attribute vor, damit POSIX-Draft-ACLs direkt dargestellt und das tatsächlich zur Zugriffsentscheidung verwendete Modell ausgewiesen werden kann.
  • Bei objektbezogenem Geltungsbereich kann ein älterer Client die wahre Form wechseln und die Erlaubnisregeln des anderen Modells löschen; AUDIT/ALARM bleibt daneben bestehen.
  • Eine prüfbare Kette trennt Fähigkeit, Modell, geordnetes Schreiben, atomaren Rücklesewert, Identität, Mask-Auswertung, Operationsentscheidung und Dateiwirkung.

Ein erfolgreicher Schreibvorgang ersetzt die Regeln

Ein Verzeichnis verwendet eine POSIX-Draft-ACL als wahre Form. Eine benannte Gruppe trägt ein Schreibbit, dessen effektive Wirkung durch den Mask-ACE begrenzt wird. Ein kompatibler Client liest Zugriffs- und Standard-ACL sowie den Modus korrekt zurück.

Später schreibt ein älteres Werkzeug dacl. Bei ACL_SCOPE_FILE_OBJECT kann der erfolgreiche SETATTR genau dieses Objekt auf ACL_MODEL_NFS4 umstellen und die POSIX-Zugriffs- und Standard-ACLs löschen. Erfolg belegt die angenommene Zustandsänderung, nicht die Bewahrung der bisherigen Politik.

Auch der Gegenweg löscht Zustand: Eine nichtleere POSIX-ACL kann ein NFSv4-Objekt auf POSIX Draft umstellen und dessen ALLOW/DENY-dacl entfernen. AUDIT/ALARM-ACEs bleiben logisch getrennt. Die Meldung „ACL aktualisiert“ verschweigt somit, welches Modell die nächste Anfrage tatsächlich ablehnen kann.

Revision 02 vom 7. September 2026 ist ein aktiver Standards-Track-Internet-Draft der NFSv4-Arbeitsgruppe und läuft am 11. März 2027 aus. Sie ist kein RFC, keine Pflichtfunktion und kein Nachweis allgemeiner Produktkonformität oder Nutzung.

Vier Attribute geben der Aussage Koordinaten

acl_trueform unterscheidet NFSv4, POSIX Draft und keine ACL. acl_trueform_scope bindet diese Wahl an Objekt, Dateisystem oder Server. posix_access_acl regelt das aktuelle Objekt; posix_default_acl liefert Vererbungsdaten für künftig erzeugte Kinder eines Verzeichnisses.

Unterstützung kommt als Paket. Wer ein True-Form-Attribut implementiert, muss beide anbieten. Ein Dateisystem mit einer POSIX-ACL muss beide ACLs, beide Formattribute sowie mode und mode_umask unterstützen.

Trotzdem beweist eine NFSv4.2-Sitzung die Fähigkeit nicht. Der Client kann die Erweiterung nicht kennen, der Export sie nicht anbieten und benachbarte Objekte können unterschiedliche Modelle tragen. Der Fähigkeitsbeleg nennt Server, Export, Sitzung, Filehandle, Attributbitmap und Zeitpunkt.

Die Mask begrenzt sichtbare Gruppenrechte

Eine erweiterte POSIX-ACL enthält Eigentümer, Eigentümergruppe, andere, benannte Benutzer oder Gruppen und eine Mask. Für Gruppen ist ein Bit nur wirksam, wenn es sowohl im Eintrag als auch in der Mask steht.

Eine Oberfläche kann daher „write“ zeigen, obwohl die Mask es entzieht. Auch die unteren neun Mode-Bits genügen nicht: Bei erweiterten ACLs spiegeln die Gruppenbits die Mask, nicht zwingend Group_obj.

Zur Rekonstruktion gehören authentifizierter Principal, Namensauflösung, effektive Zusatzgruppen, Eigentümer, passende ACEs, Mask und angeforderte Operation. Eine bytegenaue ACL ohne diese Eingaben bleibt unentschieden.

Die Standard-ACL regelt nicht das Verzeichnis selbst

Die Zugriffs-ACL gilt für das Objekt. Die Standard-ACL darf nur an einem Verzeichnis hängen und wirkt bei der Erzeugung künftiger Kinder. Sie erlaubt keinen Zugriff auf das Verzeichnis, das sie trägt.

Bei der Erzeugung werden geerbte Rechte mit den Mode-Bits geschnitten. Darum gehört mode_umask zum Vertrag: Mode zuerst, dann Vererbung, danach eine ausdrücklich mitgelieferte POSIX-ACL.

Eine spätere Prüfung braucht die Standard-ACL des Elternverzeichnisses zum Erzeugungszeitpunkt, Mode/Umask, Reihenfolge und endgültigen Rücklesewert des Kindes. Der heutige Elternzustand rekonstruiert gestern nicht.

Atomar bedeutet ein Zeitpunkt

Enthält ein SETATTR Mode und POSIX-ACL, kommt Mode zuerst. Mischt das Bitmap NFSv4-acl oder dacl mit POSIX-Attributen, muss NFS4ERR_INVAL folgen. Beim Lesen sollen Form, Mode und ACLs gegenüber parallelen Änderungen atomar erfasst werden.

So entsteht kein Mischbild aus mehreren Epochen. Eine Sekunde später kann ein anderer Client dennoch ändern; ein Clusterknoten kann Identitäten anders auflösen. Der atomare Rücklesewert ist ein versionierter Beleg, keine Dauererlaubnis.

Leer ist keine Sicherheitsentscheidung

Bei objektbezogenem POSIX-Modell kann eine leere posix_access_acl die POSIX-ACL löschen und zu ACL_MODEL_NONE zurückkehren. Eine leere POSIX-Leseantwort ist aber ebenfalls vorgeschrieben, wenn NFSv4 die wahre Form ist.

Ohne acl_trueform sehen beide Fälle gleich aus. Einer kann von Mode-Bits, der andere von einer vollständigen NFSv4-ACL beherrscht werden. „Leer“ automatisch als „unbeschränkt“ zu normalisieren, macht fehlenden Kontext zur Erlaubnis.

Experimenteller Code bleibt begrenzte Evidenz

Der Draft nennt experimentelle FreeBSD-Arbeit und einen Linux-Patch. getfacl und setfacl hätten funktioniert, auch mit vielen Einträgen. Der Text betont jedoch, dass diese Angaben von Mitwirkenden stammen, nicht unabhängig überprüft wurden und weder IETF-Billigung noch Produktkatalog sind.

Sie zeigen Machbarkeit im getesteten Umfang. Release-Aufnahme, Standardaktivierung, jede Modellumstellung, jede Identitätsauflösung und reale Zugriffsentscheidungen sind damit nicht bewiesen.

Acht Belege für einen Zugriffssatz

Die Aussage „dieser Nutzer durfte schreiben“ braucht: exakte Fähigkeit; wahre Form und Scope; geordnet akzeptierten Schreibvorgang; atomaren Rücklesewert; Identität und effektive Gruppen; ACE-, Mask-, Mode- und Vererbungsrechnung; Entscheidung über die konkrete Operation; Wirkung auf Datei und Anwendung.

Die neuen Attribute stärken die ersten vier Stationen. Ihr Nutzen liegt darin, die übrigen nicht vorzutäuschen.

Quellen