Zfs: Prise en charge des ACL NFS/POSIX

Les choses sont malheureusement un peu plus compliquées qu'il n'y paraît au premier abord.

En interne, ZFS prend entièrement en charge et applique les ACL de style NFS. Malheureusement, sous Linux, les outils existants ne manipulent que les ACL de style Posix. Des travaux ont été effectués pour apporter le modèle NFS ACL à Linux sous le nom de Rich-ACL. Pour s'intégrer à la nouvelle chaîne d'outils Rich-ACL, ZFS doit fournir une interface virtuelle system.richacl xattr. Ce xattr ne serait pas stocké comme les autres xattrs mais s'intégrerait à la place avec zfs_getacl() et zfs_setacl(). Ce hook xattr serait responsable de la traduction d'un vsecattr_t vers et depuis un flux linéaire d'octets pour le xattr.

Les ACL Posix peuvent être facilement prises en charge en ajoutant quelques crochets et en exploitant les fonctions de prise en charge Posix ACL existantes. Cependant, il peut être préférable de ne pas les implémenter pour éviter les problèmes de cohérence entre Posix et les ACL riches (NFS/ZFS).

Merci pour la description. Je pense que POSIX ACL peut également être utile si certaines applications prennent en charge les ACL POSIX. Si je me souviens bien, la samba a quelque chose comme ça. rsync prend en charge ACL, mais je ne suis pas sûr qu'il ne s'agisse que de POSIX, car l'homme dit simplement "ACL". Je ne sais pas pour les autres applications.
Je veux juste dire qu'ils ne sont pas inutiles même avec la présence d'autres ACL. Et peut être considéré comme mis en œuvre à l'avenir.

Résumé des travaux requis

En interne, ZFS prend entièrement en charge et applique les ACL de style NFS. Malheureusement, sous Linux, les outils existants ne manipulent que les ACL de style Posix. Des travaux ont été effectués pour apporter le modèle NFS ACL à Linux sous le nom de Rich-ACLs (pdf). Pour s'intégrer à la nouvelle chaîne d'outils Rich-ACL, ZFS doit fournir une interface virtuelle system.richacl xattr. Ce xattr ne serait pas stocké comme les autres xattrs mais s'intégrerait à la place avec zfs_getacl() et zfs_setacl(). Ce hook xattr serait responsable de la traduction d'un vsecattr_t vers et depuis un flux linéaire d'octets pour le xattr.

Les ACL Posix peuvent être facilement prises en charge en ajoutant quelques crochets et en exploitant les fonctions de prise en charge Posix ACL existantes. Cependant, il peut être préférable de ne pas les implémenter pour éviter les problèmes de cohérence entre Posix et les ACL riches (NFS/ZFS).

Qu'en est-il d'une option de montage/propriété du système de fichiers sur QUEL modèle de sécurité doit être appliqué ? (et peut-être l'autre complètement caché même des outils de gestion, comme setfacl/getfacl).
Sur le monde Linux, les Rich-ACL sont presque inutilisées. Les ACL Posix sont beaucoup plus utilisées. Dans mes configurations typiques, l'absence d'ACL pour un système de fichiers est un obstacle.
Je pense que de cette façon, nous pouvons obtenir une implémentation ACL fonctionnelle (Posix) en beaucoup moins de temps.

Moi aussi, j'aimerais voir la prise en charge de POSIX ACL intégrée dans ZFS sous Linux. Linux est POSIX, et jusqu'à ce que les RichACL soient plus courantes (ou du moins dans le noyau), je pense que l'intégration de POSIX dans ZFS sous Linux a du sens.

J'adorerais voir ça inclus ! C'était presque un écueil pour nous, mais a décidé de vivre sans pendant quelques mois.

Lorsque les ACL sont gérées proprement, nous devons nous assurer que le correctif suivant pour ressusciter la propriété aclmode est fusionné. Ce changement a déjà été apporté aux implémentations Illumos et FreeBSD.

Problème n°742 : ressusciter la propriété "aclmode" de ZFS
https://www.illumos.org/issues/742
https://github.com/illumos/illumos-gate/commit/a3c49ce110f325a563c245bedc4d533adddb7211

Il est possible de mapper les ACL Posix < - > NFSv4.
L'IETF a un brouillon sur ce mappage : http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt
Mais il ne précise clairement que Posix => NFSv4 (unidirectionnel).

Je pense que l'approche de mappage est théoriquement la meilleure, mais elle est plus sujette aux erreurs que d'autres car le mappage 1:1 n'est pas possible.
Il y aura toujours des cas extrêmes dans lesquels un utilisateur se verra refuser (ou pire, accordé) un privilège qui n'est pas censé être refusé (ou pire, accordé).
Au moins, il devrait être accompagné d'un "gros avertissement".
Mais il n'est pas sage d'avoir une fonction de _sécurité_ qui _doit_ se rapprocher de ce qu'elle devrait faire.
Proposition : sur "équivoque" NFSv4 acl interdire TOUT accès et imprimer une erreur sur le journal du noyau.
Problème concernant cette proposition : les instantanés ne peuvent pas être corrigés manuellement.
Pour les configurer, cela ne devrait pas être un problème, car cela peut être simplement considéré comme un format de disque « impair » pour les ACL Posix.
L'héritage beaucoup plus configurable des ACL NFSv4 crée un autre ensemble de problèmes à résoudre.

Je pense qu'une première étape cette implémentation devrait pouvoir :

• écrire des ACL POSIX, lire et appliquer ce qu'il a écrit.
• écrivez-les sur le disque en tant qu'ACL NFSv4 afin que d'autres implémentations puissent également les lire et les appliquer comme prévu.
• ÉCHEC FORT avec des ACL NFSv4 non trivialement mappables écrites par d'autres implémentations.
  ** refusant TOUT accès à ces éléments.
  ** ne pas laisser les utilisateurs créer des fichiers dans des répertoires avec des indicateurs d'héritage "particuliers"
  ** peut-être avoir un "comportement d'échec" configurable sur une base par système de fichiers avec la valeur par défaut la plus sécurisée. (et pour les instantanés ??)

Par étapes successives, la logique de mappage NFSv4 => Posix peut être ajustée et rendue beaucoup plus personnalisable.

De meilleures idées ?

Cela me semble être un point de départ raisonnable, juste quelques commentaires.

Bien qu'un mappage 1:1 parfait ne soit pas possible, les choses ne sont pas si mauvaises en fait. Comme vous le soulignez, il existe un mappage IETF Posix -> NFSv4 bien spécifié qui peut être utilisé pour définir les ACL correctes sur le disque. Une fois défini sur le disque en tant que SA, l'implémentation zfs existante devrait commencer à les appliquer indépendamment des crochets ACL Linux génériques dans le VFS.

Vous devrez alors bien sûr implémenter un mappage NFSv4 -> Posix raisonnable pour lire les ACL. Cependant, des implémentations raisonnables de ceci existent déjà. Par exemple, le serveur du noyau Linux nfs qui est obligé de stocker toutes ses ACL NFSv4 en tant que ACL Posix, ce qui est une opération avec perte. Soit dit en passant, à plus long terme, exposer la liste de contrôle d'accès nfsv4/zfs brute serait une bonne chose pour le serveur du noyau nfs. Vous pourriez potentiellement éviter une conversion inutile NFSv4 -> Posix -> NFSv4.

Enfin, nous voudrions avoir une suite de tests pour vérifier que nous avons bien compris. C'est une fonction de sécurité après tout. Heureusement, je crois comprendre que plusieurs bonnes suites de tests existent déjà.

Il y a un travail en cours sur les richacls d'Aneesh Kumar, Andreas Gruenbacher sur les travaux antérieurs de Greg Banks. Des correctifs ont été soumis pour la fusion de la ligne principale 3.1, mais en raison de certains changements, cela prendra du temps et sera fusionné dans la prochaine version.
Lien vers les correctifs : - https://lkml.org/lkml/2011/10/18/279

Une fois que cela arrive à la ligne principale, nous pouvons les utiliser pour prendre en charge nfsv4acls pour ZFS.

Une fois que cela arrive à la ligne principale, nous pouvons les utiliser pour prendre en charge nfsv4acls pour ZFS.

Et qu'en est-il des ACL POSIX ? Brian a dit qu'il n'est pas si difficile de les implémenter en utilisant xattr. Cela peut-il aussi être fait par quelqu'un, s'il vous plaît. :)

ZFS prend en charge nfsv4acls, donc à mon humble avis, nous devrions d'abord prendre en charge nfsv4acls et voir si posix acls est vraiment nécessaire. Si oui, nous pouvons trouver le moyen de définir un mappage entre eux.

Je ne vois aucune raison pour laquelle les deux ne peuvent pas être faits. Maxximino travaille actuellement sur la prise en charge de l'interface system.posixacl xattr via une traduction bien documentée. L'ajout de l'interface system.richacl xattr peut être pris en charge lorsqu'elle est intégrée et qu'une véritable chaîne d'outils est disponible.

"travailler actuellement" comme le permettent les tâches académiques et professionnelles, mais en haute priorité pour le temps "libre".
J'ai déjà examiné le code sous licence IllumOs CDDL et trouvé du code qui effectue la traduction NFSv4 <-> posix acl. Ce devrait être une base solide, du point de vue de l'exactitude. Détails sur demande.

Je sais que solaris ne fournit que deux copies de chmod pour gérer les listes de contrôle d'accès. Malheureusement, c'est très maladroit et maladroit. Je propose que nous utilisions un programme d'aide, setzacl, getzacl ou similaire pour fournir des fonctionnalités de visualisation et de modification des ACL sur zfs sous Linux. De préférence, l'interface doit être créée pour être similaire (ou compatible avec) solaris chmod, éventuellement améliorée, mais standardisée dans les deux implémentations zfs linux, et de préférence capable de gérer les futurs systèmes de fichiers avec les acls "nfs4". (Si quelqu'un peut expliquer pourquoi ils sont appelés ACL nfs4, ce serait également d'une grande aide !)

J'ajouterais que les utilisateurs de Samba pourraient aimer s'en tenir aux ACL nfs4, notamment car ils se rapprochent le plus de la correspondance des ACL Windows NTFS fonctionnalité par fonctionnalité. Cela est important lorsque vous souhaitez utiliser Samba en tant que serveur pour les dossiers d'accueil et de profil des utilisateurs dans un environnement Active Directory où les nouvelles versions de Windows recherchent des ACL spécifiques. De plus, l'interopérabilité de Windows était l'un des objectifs de conception de ZFS à l'époque de Sun, il serait donc triste de le voir disparaître...

Cela dit, je comprends parfaitement la motivation pour la conformité POSIX.

aarcane - Voir http://wiki.linux-nfs.org/wiki/index.php/ACLs pour l'historique des ACL NFSv4.

J'expérimente actuellement un partage Samba 4 DC et ZFS CIFS; le système de base est Ubuntu 12.04.

Les clients XP Pro SP3 peuvent voir et administrer Active Directory (utilisateurs et ordinateurs) et définir correctement les autorisations NTFS sur les dossiers partagés depuis EXT4.

Les dossiers partagés à partir de ZFS deviennent impossibles à parcourir via CIFS dès que vous modifiez leurs autorisations via l'interface graphique XP (bien que vous puissiez toujours y accéder - comme prévu - à partir de la ligne de commande du serveur).

Je suppose que c'est le résultat des problèmes décrits dans le fil ci-dessus? Toute idée de contournement serait la bienvenue.

L'activation de l'administration NTFS ACL complète via Samba 4 serait un énorme bonus pour ZFS.

Pouvez-vous s'il vous plaît poster plus de détails sur votre problème? Version exacte de Samba4, quel serveur de fichiers utilisez-vous (smbd ou ntvfs) et les paramètres pertinents ? (par exemple, utilisez-vous vfs_acl_xattr ou quelque chose de similaire ?)
Peut-être ouvrir un autre problème, SI la même configuration Samba4 fonctionne sur extY monté sans option "acl".

À propos de la manipulation de véritables ACL NFSv4 (de type NTFS) via Samba, cela ne peut être fait _de manière propre_ qu'après la fusion des correctifs "Rich ACL" dans le noyau.

Merci Maximino.
J'utilise Samba 4.0.0 alpha19.
J'essaie uniquement de serveur de fichiers avec ntvfs (sudo /usr/local/samba/sbin/samba -i -M single) - qui sert les partages netlogon et sysvol à partir d'ext4 et mes partages zfs à partir d'une paire de lecteurs en miroir avec aclinherit= ensemble de passage.
Aucun module vfs_acl_xattr n'est utilisé.

"À propos de la manipulation de véritables ACL NFSv4 (de type NTFS) via Samba, cela ne peut être fait de manière propre qu'après la fusion des correctifs "Rich ACL" dans le noyau."

Pour autant que je sache, les correctifs officiels de richacls ne prennent en charge que EXT4 - êtes-vous en train de dire que si j'utilise par exemple opensuse (avec richacls inclus par défaut) ou patch richacls dans ubuntu / debian, zfs+samba4+ntfs acls devrait "juste commencer à travailler "?

J'ai reproduit votre problème.
Vous n'utilisez pas explicitement vfs_acl_xattr, mais Samba4 fait la même chose "en silence". Il enregistre ses ACL dans le xattr nommé "security.NTACL" (que vous pouvez voir avec getfattr -n security.NTACL $FILENAME ; et supprimer avec setfattr -x security.NTACL $FILENAME).
Cet attribut n'est pris en compte que par Samba, pas par quoi que ce soit dans le noyau zfs/linux. Puisqu'un simple programme perl qui enregistre les valeurs de /dev/urandom dans xattrs dans zfs, peut les relire sans corruption, je pense vraiment qu'il s'agit d'un problème Samba4.
Le problème ne s'affiche que sur zfs PROBABLEMENT car sur d'autres fs, il peut mapper ses ACL sur les ACL Posix au lieu d'utiliser xattrs.

Non, il ne suffit pas de simplement patcher un noyau avec des patchs acl riches. Lorsque ces correctifs arrivent sur la ligne principale, il est possible de commencer à intégrer un support riche en acl dans zfs.

Je suis juste en train de construire Samba 4 sur Suse ; Je pense que j'étais sur le point de reproduire votre reproduction sous un autre angle.
M'a épargné la douleur.

Peut-être qu'une solution de contournement raisonnable (à court terme) serait de servir des fichiers à partir de zfs via un environnement Samba 3 stable, en s'authentifiant par rapport à un DC Samba 4 dans un autre Linux-VServer par exemple ?

À moyen terme, l'utilité d'avoir des partages CIFS basés sur ZFS combinés à Samba 4 AD, tous basés sur un système d'exploitation Linux avec une excellente prise en charge matérielle générique _dans la même machine_ ne peut pas être surestimée. Les applications pour les petites entreprises/à but non lucratif sont énormes.

Merci pour tout le travail jusqu'à présent.

Je suis tombé sur le fil suivant :
https://lists.samba.org/archive/samba/2012-August/168660.html

Le résumé est que Samba 4 a un module acl appelé vfs_zfsacl, qui est utilisé sur Solaris, afin que Samba puisse utiliser les acls ZFS natifs. Serait-il possible d'utiliser ce module avec zfsonlinux ? Les API nécessaires sont-elles mises à disposition de l'espace utilisateur sous Linux ?

@kisg C'est une bonne question, c'est la première fois que j'entends parler du module vfs_zfsacl pour Samba. Quelqu'un devra faire quelques démarches pour déterminer à quelle interface ils s'attendent. Selon ce que c'est, nous pourrions être en mesure de le fournir. Bien que si aucune traduction n'est effectuée, vous aurez toujours le problème de ne pas pouvoir gérer les ACL sur la machine Linux.

J'ai regardé rapidement la source.
Vous pouvez trouver la version de branche Samba v4-0-stable de vfs_zfsacl.c ici : git.samba.org .

Il convertit simplement la représentation Samba interne en API SunOS NFSv4 acl/facl native. Cette API est également implémentée sur FreeBSD en utilisant une enveloppe d'espace utilisateur mince autour de sa propre implémentation d'acl NFSv4.

Sur la base de cette analyse, nous ne pouvons pas réutiliser cette implémentation sur Linux. Au lieu de cela, si l'intégration richacl de zfsonlinux est terminée, nous pourrions utiliser la bibliothèque librichacl pour créer un module vfs_richacl tout aussi simple (espérons-le moins de 1000 lignes) pour Samba.

D'après mon examen rapide des correctifs du noyau richacl, il semble que l'intégration de zfsonlinux pourrait même être effectuée sans réellement corriger le noyau, en tirant simplement les parties requises (structures de données et conversion xattr) du code richacl dans l'arborescence zfs pour les versions du noyau qui ne le supporte pas nativement. C'est important pour nous, car nous (mon entreprise) aimerions exécuter un noyau Ubuntu LTS standard et n'importer zfsonlinux que comme module supplémentaire.

Cependant, je ne sais pas si richacl est toujours maintenu (son référentiel n'est pas vraiment tenu à jour) et en voie d'être inclus dans le noyau vanille.

J'ai contacté l'auteur du patchset richacl. Il m'a indiqué le module expérimental richacl vfs suivant : v4acls-experimental/samba.git

Il semble donc que presque toutes les pièces soient en place (ou du moins existent sous forme expérimentale) à l'exception du support richacl dans zfs lui-même.

Peut-être que le portage de libsunacl.c vers Linux pourrait être suffisant du côté de la samba ?

http://sourceforge.net/projects/libsunacl/

mais pour autant que je sache, "aclmode" sera toujours manquant sur zfsonlinux.

Je ne sais même pas pourquoi nous n'avons pas encore une forme de support ACL. Pourquoi avoir
zfs acls n'a pas été activé ? Je connais le code pour un chmod et un ls
exist.un getzacl de style getfacl aurait dû être fourni maintenant.Je suis sûr
il y a cependant une bonne raison pour le manque d'acls.
Le 15 février 2013 à 14h07, "franx" [email protected] a écrit :

Peut-être que le portage de libsunacl.c vers Linux pourrait être suffisant du côté de la samba ?

http://sourceforge.net/projects/libsunacl/

mais pour autant que je sache, "aclmode" sera toujours manquant sur zfsonlinux.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/zfsonlinux/zfs/issues/170#issuecomment -13630736.

zfs acl est pris en charge
test:
créer un fichier sur un partage smb sur un autre système de fichiers avec l'option de montage acl activée, définir ACL sur Windows.

déplacez ce fichier sur un volume zfsonlinux avec aclinherit=passthrough
les acls sont préservés.

Wath atm n'a pas de solution, c'est de le faire en samba ..

aucun des acl_xattr ou acl_tdb ne fonctionne correctement sous une telle configuration, sur bsd ils utilisent le vfs_zfsacl

à travers libsunacl qui ressemble à un traducteur de zfs2bsd

Ma question est peut-être stupide, mais je veux comprendre clairement si nous avons un support ACL ou non. J'ai créé le serveur minimal VBox ubuntu 12.04 LTS, puis installé ubuntu-zfs, créé des commandes pool w

Historique de 'mypool' :
2013-05-05.15:12:49 zpool créer -f mypool /dev/disk/by-id/ata-VBOX_HARDDISK_VB88a04e0d-d8d1e7a4

Historique de 'réservoir' :
2013-04-30.13:44:54 zpool créer un réservoir /root/vol1
2013-05-01.00:13:33 zfs set aclinherit=réservoir de passage
2013-05-05.13:50:14 zfs set dedup=on tank

tank supporte setfacl sans problème
mypool ne le fait PAS et indique que l'opération n'est pas prise en charge.

Je veux utiliser zfs avec samba et je dois contrôler l'accès de plusieurs utilisateurs aux dossiers. comme ça
root@server :~# setfacl -mg: UTILISATEURS :--- test4v007/

Je souhaite implémenter le correctif richacls pour ZFS, mais comme je suis totalement inexpérimenté avec ZFS, ce serait bien si l'un des développeurs de ZFSonLinux peut fournir de l'aide (principalement sous forme d'astuces et de discussions).

J'aimerais donner un coup de pouce...

@behlendorf - Maintenant que vous avez une version stable du système de fichiers, avons-nous un calendrier solide pour quand cela sera fait ? Je sais que vous l'avez arrêté pour l'étape 0.8, mais au rythme de sortie actuel, il semble que cela pourrait prendre quelques années - pouvons-nous le faire avancer de quelque manière que ce soit ?

Nous voulons aller de l'avant avec le déploiement de nos serveurs NAS de stockage de profil avec Samba, mais ne pas avoir d'ACL peut signifier que nous devons nous en tenir à FreeBSD, ce que nous ne voulons vraiment pas faire puisque toute notre base d'expérience est avec Linux.

J'espère que ce n'est pas complètement hors-sujet.
Avez-vous essayé Debian kFreebsd ?

C'est presque comme une sorte de Linux.

@sopmot - Vous savez, je l'ai déjà regardé et je l'ai rejeté comme n'étant pas prêt pour la production, mais j'ai eu une lecture rapide à ce sujet et il semble qu'il soit peut-être un peu plus prêt au combat que ZoL pour ce dont nous avons besoin si nous le fais tout de suite.

Alors bravo, merci de m'avoir mis sur la bonne voie - Toutes mes excuses pour l'impolitesse.

Je continue à regarder kfreebsd, et il manque iscsi, nfsv4 et un
équivalent à la virtualisation kvm. J'étais sérieux au sujet de l'utiliser pour root
jusqu'à ce que ces lacunes deviennent apparentes
Le 19 mai 2013 à 9h50, "Tamas Papp" [email protected] a écrit :

J'espère que ce n'est pas complètement hors-sujet.
Avez-vous essayé Debian kFreebsd ?

C'est presque comme une sorte de Linux.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/zfsonlinux/zfs/issues/170#issuecomment -18120673
.

J'aimerais aussi que cela soit abordé. Je manque malheureusement de temps ces jours-ci (en plus je ne connais rien aux trucs de bas niveau/noyau), donc je ne peux pas faire grand-chose pour m'aider :( Vraiment, je cherche juste un bon moyen de appliquer certaines autorisations pour les nouveaux fichiers dans certains répertoires ; je mets souvent des fichiers dans un dossier accessible au public et ce serait bien s'ils pouvaient être automatiquement configurés avec des autorisations assouplies, car je ne veux pas vraiment définir mon umask sur quelque chose donc libéral pour la plupart des fichiers que je crée, qui se retrouvent dans mon dossier personnel. Dans OSOL/FreeBSD, je le ferais en utilisant les ACL NFSv4, bien que je sois ouvert à de meilleures solutions si quelqu'un a des idées. La seule autre chose à laquelle je peux penser of est d'exécuter un cronjob qui définit récursivement les perms sur les répertoires pertinents toutes les demi-heures ou quelque chose du genre, mais c'est tellement inélégant !

Pour info afin que les gens ne fassent pas la même erreur que moi - Debian kFreeBSD est idéal pour la prise en charge de ZFS, mais les ACL ne fonctionnent toujours pas depuis l'espace utilisateur, vous obtenez simplement "Fonction non implémentée" - voir bogue Debian : http:// bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573

@iamacarpet Cela peut arriver dès que quelqu'un qui a besoin de cette fonctionnalité a le temps de travailler dessus. Actuellement, les principaux moteurs du projet n'ont pas beaucoup d'utilité pour les ACL, ils sont donc en bas de la liste des priorités. Mais rien n'empêche quelqu'un qui a besoin de ce soutien de se lancer et de le faire plus tôt. Désolé, mais c'est juste la réalité de la situation.

Bonjour,

nous utilisons zfsonlinux dans une appliance de sauvegarde et nous pensons que les ACL sont importantes à des fins d'intégration. Certaines opérations courantes, telles que la modification des autorisations dans un volume partagé ZFS à partir d'un ordinateur Windows, sont nécessaires.

ACL est-il toujours dans la feuille de route ?

Merci.

@n1mh Il est prévu pour la version 0.8.0.

Grâce à @maxximino, la prise en charge des ACL Posix a été implémentée. J'ai ouvert la pull request #1809 avec une version proche de la version finale du correctif qui est prête pour des tests plus larges. Il passe proprement la section ACL de Posix Test Suite et nous n'avons connaissance d'aucun problème en suspens.

Pour ceux qui aimeraient cette fonctionnalité, il serait très utile que vous puissiez tester le correctif proposé avec une charge de travail réaliste. Veuillez vérifier qu'il se comporte comme vous l'attendriez dans votre environnement. Les ACL Posix sont désactivées par défaut mais peuvent être activées en définissant la propriété _acltype_ sur l'ensemble de données.

zfs set acltype=posixacl pool/dataset

Les ACL Posix de style Linux ont été implémentées en tant que xattr et fusionnées dans master. Elles sont stockées indépendamment des ACL NFS natives et n'entreront pas en conflit. La nouvelle propriété de jeu de données acltype a été ajoutée pour activer cette fonctionnalité. Pour de meilleures performances, vous êtes fortement encouragé à définir à la fois acltype=posixacl et xattr=sa . Pour plus de détails, consultez la page de manuel mise à jour :

       acltype=noacl | posixacl

           Controls  whether  ACLs  are  enabled and if so what type of ACL to
           use.  When a file system has the acltype property set to noacl (the
           default)  then  ACLs are disabled.  Setting the acltype property to
           posixacl indicates Posix ACLs should be used.  Posix ACLs are  spe-
           cific  to  Linux  and are not functional on other platforms.  Posix
           ACLs are stored as an xattr and therefore will  not  overwrite  any
           existing ZFS/NFSv4 ACLs which may be set.  Currently only posixacls
           are supported on Linux.

           To obtain the best performance  when  setting  posixacl  users  are
           strongly encouraged to set the xattr=sa property.  This will result
           in the Posix ACL being stored more efficiently on disk.  But  as  a
           consequence of this all new xattrs will only be accessable from ZFS
           implementations which support the xattr=sa property.  See the xattr
           property for more details.