Résumé

  • draft-ietf-nfsv4-posix-acls-02 ajoute quatre attributs facultatifs pour exposer directement les ACL POSIX Draft et identifier le modèle réellement utilisé par le serveur.
  • À la portée d’un objet, un client ancien peut remplacer le « vrai modèle » POSIX par une ACL NFSv4 et supprimer les règles POSIX ; l’écriture inverse peut effacer les ALLOW/DENY NFSv4 sans toucher aux ACE AUDIT/ALARM.
  • Une politique démontrable relie capacité, modèle et portée, écriture ordonnée, relecture atomique, identité, calcul du masque, décision sur l’opération et effet observé.

Un changement réussi peut remplacer le modèle

Prenons un répertoire régi par une ACL POSIX Draft. Une entrée accorde l’écriture à un groupe nommé, mais l’ACE Mask en fixe la limite effective. Un outil compatible lit l’ACL d’accès et l’ACL par défaut : tout paraît conforme.

Un client plus ancien modifie ensuite dacl. Si le serveur applique ACL_SCOPE_FILE_OBJECT, cette écriture peut basculer l’objet vers ACL_MODEL_NFS4 et supprimer ses ACL POSIX d’accès et par défaut. L’appel a réussi, mais la signification de la politique a changé. Une lecture POSIX peut désormais renvoyer un tableau vide, non parce que le fichier est ouvert à tous, mais parce que POSIX n’est plus son vrai modèle.

Le mouvement inverse existe aussi. Écrire une ACL POSIX non vide peut transformer un objet NFSv4 en objet POSIX Draft et supprimer son dacl ALLOW/DENY. Les ACE AUDIT/ALARM restent séparées. « ACL mise à jour » ne suffit donc jamais : il faut savoir quel modèle contrôle désormais l’accès, à quelle portée et à quel instant.

La révision 02, datée du 7 septembre 2026, est un Internet-Draft actif du groupe NFSv4 visant Standards Track et expirant le 11 mars 2027. Ce n’est ni un RFC, ni une fonction obligatoire, ni une attestation de conformité commerciale.

Les quatre attributs disent où regarder

acl_trueform distingue ACL_MODEL_NFS4, ACL_MODEL_POSIX_DRAFT et ACL_MODEL_NONE. acl_trueform_scope précise si cette décision vaut pour un objet, un système de fichiers ou tout le serveur. posix_access_acl décrit la politique d’accès à l’objet ; posix_default_acl décrit l’héritage applicable aux futurs enfants d’un répertoire.

Le projet lie ces capacités. Un serveur qui fournit l’un des attributs de vrai modèle doit fournir les deux. Un système de fichiers qui fournit une ACL POSIX doit fournir les deux ACL, les deux attributs de modèle et les mécanismes mode / mode_umask. Cette cohérence évite d’exposer un tableau sans indiquer le cadre qui lui donne sens.

Mais une capacité reste locale. Le protocole peut être NFSv4.2 tandis qu’un client ignore l’extension. Le serveur peut la connaître sans l’activer sur cette exportation. À la portée d’un objet, deux fichiers voisins peuvent employer des modèles différents. La preuve de capacité doit donc nommer serveur, exportation, filehandle, session, bitmap d’attributs et heure.

Le masque rend les apparences trompeuses

Une ACL POSIX minimale contient propriétaire, groupe propriétaire et autres. Une ACL étendue ajoute utilisateurs ou groupes nommés et une entrée Mask. Pour les groupes, un bit n’est effectif que s’il figure à la fois dans l’entrée et dans le Mask.

Un écran peut donc afficher « write » sur un groupe alors que le masque l’annule. Les neuf bits bas du mode ne suffisent pas davantage : dans une ACL étendue, les bits de groupe reflètent le Mask, pas nécessairement l’entrée Group_obj.

Reconstituer une décision exige le principal authentifié, la résolution des noms, les groupes supplémentaires effectifs, le propriétaire de l’objet, toutes les entrées pertinentes, le Mask et l’opération demandée. Une transmission XDR parfaite ne remplit aucune de ces cases à elle seule.

L’ACL par défaut ne gouverne pas le répertoire

L’ACL d’accès décide pour l’objet. L’ACL par défaut n’existe que sur un répertoire et prépare l’héritage des objets créés plus tard ; elle ne décide pas de l’accès au répertoire lui-même.

À la création, les permissions héritées sont croisées avec les neuf bits de mode. C’est pourquoi mode_umask fait partie du contrat. Pour OPEN ou CREATE, le mode est appliqué, l’héritage est calculé, puis les ACL explicitement fournies sont posées.

Une ACL par défaut est donc un matériau de fabrication, pas une autorisation permanente. Auditer un enfant suppose de conserver l’ACL du parent à l’époque de création, le mode et l’umask demandés, l’ordre des opérations et la relecture finale de l’enfant.

Une photographie atomique reste une photographie

Dans un même SETATTR, les bits de mode doivent être appliqués avant l’ACL POSIX. Mélanger acl ou dacl NFSv4 avec les attributs POSIX dans le même bitmap doit produire NFS4ERR_INVAL. Pour les lectures, le serveur devrait acquérir mode, vrai modèle et ACL de manière atomique par rapport aux écritures concurrentes.

Cette atomicité empêche une réponse composite issue de plusieurs instants. Elle ne verrouille pas l’avenir. Une seconde plus tard, un autre client peut changer le modèle ; le principal peut aussi être résolu différemment sur un autre nœud. La relecture doit être conservée comme un reçu versionné, non comme une promesse durable d’accès.

Vide ne veut pas dire sans restriction

À la portée d’un objet, écrire une ACL d’accès POSIX vide peut supprimer les ACL POSIX et revenir à ACL_MODEL_NONE. À la lecture, les tableaux POSIX doivent aussi être vides si le vrai modèle n’est pas POSIX.

Sans acl_trueform, les deux situations sont indiscernables. L’une peut être gouvernée par les bits de mode, l’autre par une ACL NFSv4. Transformer mécaniquement « tableau vide » en « aucune restriction » est précisément l’erreur que les nouveaux attributs permettent d’éviter.

Les essais montrent la faisabilité, pas l’universalité

Le projet mentionne des essais expérimentaux FreeBSD et un patch Linux. getfacl et setfacl auraient fonctionné, y compris avec de nombreuses entrées. Le texte précise toutefois que ces informations viennent des contributeurs, n’ont pas été vérifiées indépendamment et ne constituent ni approbation IETF ni catalogue de produits.

Cette exécution compte : elle montre qu’une implémentation est possible. Sa portée reste limitée aux versions, systèmes de fichiers, configurations et vecteurs testés. Elle ne prouve ni intégration dans une version publiée, ni activation par défaut, ni correction de toutes les décisions d’accès.

Huit reçus au lieu d’un écran vert

Une preuve exploitable suit huit étapes : capacité exacte du client et du serveur ; vrai modèle et portée ; écriture ordonnée acceptée ; relecture atomique ; identité et groupes effectifs ; calcul des entrées, du Mask, du mode et de l’héritage ; décision sur l’opération réelle ; effet final sur le fichier et l’application.

Les nouveaux attributs renforcent surtout les quatre premières étapes. Ils deviennent plus utiles lorsque l’on refuse de leur faire jouer le rôle des quatre suivantes.

Sources