Paul042020
Contributor
- Joined
- May 4, 2020
- Messages
- 118
Bonjour,
Ayant récemment installé Truenas 13, alors que j'étais sur Freenas 9.3, je me suis retrouvé confronté à une arlésienne (du niveau de Keyser Söze : tout le monde en a entendu parlé, mais personne ne l’a jamais vu) : les ACLs
Ah ces fameux ACLs, c’est un sacré morceau. Il y a des dizaines de posts sur le forum de Truenas et pas vraiment de documentation qui explique les options, le paramétrage...
Vu que j’en ai besoin, j’ai effectué beaucoup de tests, lu beaucoup d’articles, de posts sur les forums. Je vais essayer d’expliquer dans cet article ce que j’ai compris, et de compiler des informations qui m’ont parues importantes et ainsi partager ma maigre expérience.
Tout ce que je vais écrire n’est que mon interprétation. Je suis totalement novice en la matière, donc certains éléments ne seront peut-être pas tout à fait la réalité.
Dans mon cas, il s’agit d’une installation domestique, donc assez simple.
Voici la configuration :
Une des première question à se poser, quel type d’OS vont se connecter aux partages.
En ce qui me concerne, il y aura un PC Windows, un PC Linux, et des ordiphones Android. C’est tout naturel que je choisisse le protocole SMB.
A ce stade, il est important d’avoir à l’esprit que le choix du « type de partage » va influencer la création des datasets.
Lorsqu’on créé un dataset, dans Stockage > Volumes > Ajouter un dataset > Options avancées > Autres options > le paramètre « Type de partage » va directement influencer les paramètres :
En effet, « Type de partage » offre deux possibilités :
Aparté sur la notion de « sensibilité à la casse » :
Il s’avère par ailleurs que le paramètre « Sensibilité à la casse » est irrévocable. Une fois le dataset créé, il ne sera pas possible de modifier ce choix. La seule solution sera de créer un nouveau dataset avec le bon paramètre, copier les données et supprimer le datatset initial.
Ce post (https://askubuntu.com/questions/137...-to-be-settable-post-creation-but-its-read-on) donne des informations sur quelques une des raisons pour lesquelles il n’est pas possible de modifier le choix de la sensibilité à la casse après la création du dataset. En autre, pour des raisons de risque de conflits de fichiers dans la cas où un dataset paramétré comme « sensible à la casse » serait soudainement défini avec un paramétrage « insensible à la casse ». Dans un tel cas, comment le système traiterait les fichiers d’un répertoire portant les noms suivants « Toto » et « tOtO ?
Par ailleurs, dans ce même post on apprend également qu'à l'heure où j'écris ces lignes (novembre 2022), la sensibilité à la casse de type « Mixed » est seulement pris en charge sur les serveurs SMB (https://manpages.ubuntu.com/manpages/focal/en/man8/zfs.8.html).
Donc par déduction, il semble que ce mode puisse poser le même genre de problème (conflits de fichiers) dans le cas d’un accès multi-protocoles aux datasets.
Tout cela pour dire que même si on choisit le mode « Generic », il est sans doute préférable de choisir une sensibilité à la casse de type « Insensitive » (à moins de vraiment savoir ce qu’on fait).
Nous avons donc vu que porter son choix sur le type de partage « SMB » contraint les paramètres « Sensibilité à la casse » et « Mode ACL ».
Ce choix provoque également la création d’une liste d’ACL par défaut disponible dans Stockage > Volumes > cliquer « actions » du dataset souhaité (3 points en bout de ligne) > Modifier les autorisations :
Je ne sais pas si ce choix provoque d’autres paramétrages non-visibles directement dans l’interface web.
Quelques commandes utiles
Dernière valeur que je n’ai pas évoqué : aclmode=passthrought
C’est cette valeur qui m’a le plus donné de fil à retordre.
Quelques informations sur cette page (https://serverfault.com/questions/858421/what-is-the-difference-between-aclinherit-and-aclmode).
Personnellement, je ne comprends pas du tout la différence entre aclmode=restricted et aclmode=passthrough.
Tout ce que je peux vous dire c’est vous faire part d’un retour d’expérience sur mes tests.
Comme au début de mes tests, je savais que j’accéderai à mes partages via plusieurs plateformes (Windows / Linux), j’avais donc choisi « Generic » comme type de partage et j’avais laissé les valeurs par défaut, à savoir :
Quelques règles sur les ACLs
1] Contrairement aux permissions UNIX qui sont binaires (autorisation ou non), il est possible de configurer une entrée ACL, soit définies sur :
Les permissions définies sur « refuser » sont semble-t-il prioritaires sur les permissions définies sur « autoriser ».
Les permissions « non-définie » symbolisées par « - » sont en faite des autorisations implicites de « refus ».
La grande question, à laquelle je n’ai pas trouvé de réponse : est-ce qu’une autorisation « non-définie » équivaut-elle à une autorisation explicitement définie sur « refuser ».
Un droit est composée de la façon suivante :
Sources :
https://www.truenas.com/docs/core/coretutorials/storage/pools/permissions/
https://svennd.be/blog/2022-03-29-truenas-acl/
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/6mhupg6p1/index.html#gbbht
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/6mhupg6p4/index.html#gbbhx
Truenas propose 4 type d'autorisations prédéfinies (type "base") :
2] « owner@ », « group@ » et « everyone@ » :
Sources :
https://www.truenas.com/community/threads/file-rights-acl-please-kill-me-now.91439/post-633456
https://www.truenas.com/community/threads/11-3-acl-management-explain-root-wheel-owner-group.81801/
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/gbchf/index.html
3] Vous pouvez vous apercevoir que tous les nouveaux utilisateurs sont automatiquement ajoutés au groupe « builtin_user ».
A ce sujet, inutile de créer des groupes « invités » ou « administrateurs », Truenas dispose maintenant de ces groupes génériques :
4] Notions :
Lorsqu’on créé un partage SMB, par défaut, une « ACL de partage » de type [contrôle totale - autoriser- Everyone] est créée.
Sur cette page (https://www.truenas.com/community/t...e-between-smb-acls-and-filesystem-acls.90046/)
@anodos donne beaucoup d’information :
A priori d’après ce même post, il est préférable de laisser « l’ACL de partage » définie par défaut par Truenas au moment de la création du partage SMB (donc : full control – allowed – Everyone).
Sécurité SMB
On trouve sur cette page de la documentation Truenas quelques conseils de sécurité (https://www.truenas.com/docs/solutions/optimizations/security/#smb) :
Pour cela, se rendre dans Services > SMB > cliquer sur « Configurer » (crayon) > cliquer sur le bouton « Options avancées » > Paragraphe « Autres options » > Champs « Paramètres auxiliaires » > ajouter : « server signing = mandatory » > cliquer sur le bouton « Enregistrer » > redémarrer le service SMB.
Ayant posé la question sur le forum international (https://www.truenas.com/community/threads/smb-security-server-signing.106132/), il s'avère que la page de la documentation Truenas (donnée ci-dessus) n'est pas tout à fait à jour ou mal rédigé.
A priori, la signature est déjà intégré dans les protocoles SMB 2 et 3. Ce paramètre est donc inutile ici.
Cette option se trouve dans Services > SMB > cliquer sur « Configurer » (crayon) > paragraphe « NetBIOS » > case « NTLMv1 Auth »
Comme on peut le voir sur la capture d'image ci-dessous, ce paramètrage a activé certaines options et en a désactivé d'autres. De plus dans ce mode, la modification du paramétrage est bloqué.
On verra dans la suite des tests effectué dans ce post, qu'il nous faudra activer / désactiver la case « Activer les ACL ». Il faudra donc définir le champs « Objectif » sur « No presets » pour modifier le paramétrage par défaut.
Ayant récemment installé Truenas 13, alors que j'étais sur Freenas 9.3, je me suis retrouvé confronté à une arlésienne (du niveau de Keyser Söze : tout le monde en a entendu parlé, mais personne ne l’a jamais vu) : les ACLs
Ah ces fameux ACLs, c’est un sacré morceau. Il y a des dizaines de posts sur le forum de Truenas et pas vraiment de documentation qui explique les options, le paramétrage...
Vu que j’en ai besoin, j’ai effectué beaucoup de tests, lu beaucoup d’articles, de posts sur les forums. Je vais essayer d’expliquer dans cet article ce que j’ai compris, et de compiler des informations qui m’ont parues importantes et ainsi partager ma maigre expérience.
Tout ce que je vais écrire n’est que mon interprétation. Je suis totalement novice en la matière, donc certains éléments ne seront peut-être pas tout à fait la réalité.
Dans mon cas, il s’agit d’une installation domestique, donc assez simple.
Voici la configuration :
- 5 datasets :
- jean
- marie
- gabin
- parents
- media
- 3 utilisateurs :
- jean
- marie
- gabin
- 4 groupes :
- jean
- marie
- gabin
- parents (jean & marie)
Une des première question à se poser, quel type d’OS vont se connecter aux partages.
En ce qui me concerne, il y aura un PC Windows, un PC Linux, et des ordiphones Android. C’est tout naturel que je choisisse le protocole SMB.
A ce stade, il est important d’avoir à l’esprit que le choix du « type de partage » va influencer la création des datasets.
Lorsqu’on créé un dataset, dans Stockage > Volumes > Ajouter un dataset > Options avancées > Autres options > le paramètre « Type de partage » va directement influencer les paramètres :
- « Sensibilité à la casse » ;
- « Mode ACL ».
En effet, « Type de partage » offre deux possibilités :
- « Generic » :
- « Sensibilité à la casse » : choix entre « Sensitive » ou « Insensitive » ou « Mixed »
- « Mode ACL »: choix entre « Passthrough » ou « Restricted »
- « SMB » :
- « Sensibilité à la casse » : « Insensitive »
- « Mode ACL » : « Restricted »
Aparté sur la notion de « sensibilité à la casse » :
- GNU/Linux & BSD sont des systèmes dits « sensible à la casse » car une distinction est faite entre une lettre écrite en majuscule et la même lettre écrite en minuscule. Par exemple : toto ≠ Toto ≠ toTO.
- Windows est un système dit « insensible à la casse » car il ne fait pas la distinction entre une lettre écrite en majuscule d’une lettre écrite minuscule. Par exemple : Toto = TOTO = totO = Toto
Il s’avère par ailleurs que le paramètre « Sensibilité à la casse » est irrévocable. Une fois le dataset créé, il ne sera pas possible de modifier ce choix. La seule solution sera de créer un nouveau dataset avec le bon paramètre, copier les données et supprimer le datatset initial.
Ce post (https://askubuntu.com/questions/137...-to-be-settable-post-creation-but-its-read-on) donne des informations sur quelques une des raisons pour lesquelles il n’est pas possible de modifier le choix de la sensibilité à la casse après la création du dataset. En autre, pour des raisons de risque de conflits de fichiers dans la cas où un dataset paramétré comme « sensible à la casse » serait soudainement défini avec un paramétrage « insensible à la casse ». Dans un tel cas, comment le système traiterait les fichiers d’un répertoire portant les noms suivants « Toto » et « tOtO ?
Par ailleurs, dans ce même post on apprend également qu'à l'heure où j'écris ces lignes (novembre 2022), la sensibilité à la casse de type « Mixed » est seulement pris en charge sur les serveurs SMB (https://manpages.ubuntu.com/manpages/focal/en/man8/zfs.8.html).
Donc par déduction, il semble que ce mode puisse poser le même genre de problème (conflits de fichiers) dans le cas d’un accès multi-protocoles aux datasets.
Tout cela pour dire que même si on choisit le mode « Generic », il est sans doute préférable de choisir une sensibilité à la casse de type « Insensitive » (à moins de vraiment savoir ce qu’on fait).
Nous avons donc vu que porter son choix sur le type de partage « SMB » contraint les paramètres « Sensibilité à la casse » et « Mode ACL ».
Ce choix provoque également la création d’une liste d’ACL par défaut disponible dans Stockage > Volumes > cliquer « actions » du dataset souhaité (3 points en bout de ligne) > Modifier les autorisations :
utilisateur propriétaire: root
groupe propriétaire: wheel
owner@: autoriser – full control – hériter
group@: autoriser – full control – hériter
everyone@: autoriser – traverser – non-hériter
group : builtin_users: autoriser – modification – hériter
Je ne sais pas si ce choix provoque d’autres paramétrages non-visibles directement dans l’interface web.
Quelques commandes utiles
- permettre de voir la liste de toutes les propriétés et les valeurs possibles associées :
zfs list -o
- renvoyer la valeur définie sur le champ « ACL mode » du dataset :
zfs list -o aclmode </mnt/chemin_du_datatset>
- renvoyer la valeur définie sur le champ « sensibilité à la case » du dataset :
zfs list -o casesensitivity </mnt/chemin_du_datatset>
- renvoyer toutes les valeurs définies sur toutes les propriétés d’un dataset :
zfs get all </mnt/<chemin_du_dataset>
- mettre la propriété « aclmode » sur la valeur « restrited » :
zfs set aclmode=restrited </mnt/<chemin_du_dataset>
Dernière valeur que je n’ai pas évoqué : aclmode=passthrought
C’est cette valeur qui m’a le plus donné de fil à retordre.
Quelques informations sur cette page (https://serverfault.com/questions/858421/what-is-the-difference-between-aclinherit-and-aclmode).
Personnellement, je ne comprends pas du tout la différence entre aclmode=restricted et aclmode=passthrough.
Tout ce que je peux vous dire c’est vous faire part d’un retour d’expérience sur mes tests.
Comme au début de mes tests, je savais que j’accéderai à mes partages via plusieurs plateformes (Windows / Linux), j’avais donc choisi « Generic » comme type de partage et j’avais laissé les valeurs par défaut, à savoir :
- Mode ACL : passthrouth
- Sensibilité à la casse : sensitive
Quelques règles sur les ACLs
1] Contrairement aux permissions UNIX qui sont binaires (autorisation ou non), il est possible de configurer une entrée ACL, soit définies sur :
- « autoriser » ;
- « non-défini » ;
- « refuser »
- owner@ : rwxp--aARWcCos :-------:allow
- groupe:ami : rwxpDdaARWc--s :-------:deny
Les permissions définies sur « refuser » sont semble-t-il prioritaires sur les permissions définies sur « autoriser ».
Les permissions « non-définie » symbolisées par « - » sont en faite des autorisations implicites de « refus ».
La grande question, à laquelle je n’ai pas trouvé de réponse : est-ce qu’une autorisation « non-définie » équivaut-elle à une autorisation explicitement définie sur « refuser ».
Un droit est composée de la façon suivante :
Pour info, voici la signification des différentes autorisations disponibles avec les ACLs :owner@ : rwxpDdaARWcCos:dfin-SFI:allow
- « r » : lire les données contenu dans un fichier ou affiche le contenu d'un répertoire.
- « w » : écrire des données, créer de nouveaux fichiers ou modifier toute partie d'un fichier.
- « x » : exécuter un fichier, se déplacer dans un répertoire ou y effectuer une recherche
- « p » : ajouter des données à la fin d'un fichier.
- « D » : supprimer les enfants. Supprimer des fichiers ou des sous-répertoires à l'intérieur d'un répertoire.
- « d » : supprimer un fichier ou un répertoire.
- « a » : visualiser les attributs non-ACL d'un fichier ou d'un répertoire.
- « A » : modifier les attributs non-ACL d'un fichier ou d'un répertoire.
- « R » : lire les attributs d’un répertoire
- « W » : modifier les attributs d’un répertoire. Doit avoir l’autorisation de lire les attributs.
- « c » : visualiser l'ACL
- « C » : changer l'ACL et le mode de l'ACL.
- « o » : changer l'utilisateur et le groupe propriétaire du fichier ou du répertoire.
- « s » : lecture/écriture synchrone de fichiers avec le serveur. Cette permission ne s'applique pas aux clients FreeBSD.
- « f » : les fichiers héritent de l'ACL du répertoire parent
- « d » : les sous-répertoires héritent de la liste de contrôle d'accès du répertoire parent
- « i » : Hérite de la liste de contrôle d'accès du répertoire parent mais ne s'applique qu'aux fichiers ou sous-répertoires nouvellement créés et non au répertoire lui-même
- « n » : Hérite uniquement de l'ACL du répertoire parent au contenu de premier niveau du répertoire, et non au contenu de second niveau ou suivant
- « - » : ???Aucune autorisation accordée ???
- « S » : Indique si un enregistrement d'alarme ou d'audit doit être déclenché en cas d'accès réussi.
- « F » : Indique si une alarme ou un enregistrement d'audit doit être déclenché lorsqu'un accès échoue.
- « I » : Indique qu'un ACE a un héritage défini
Sources :
https://www.truenas.com/docs/core/coretutorials/storage/pools/permissions/
https://svennd.be/blog/2022-03-29-truenas-acl/
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/6mhupg6p1/index.html#gbbht
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/6mhupg6p4/index.html#gbbhx
Truenas propose 4 type d'autorisations prédéfinies (type "base") :
- Lecture : r-x---a-R-c---
- Modification : rwxpDdaARWc--s
- Traverser : --x---a-R-c---
- Contrôle total : rwxpDdaARWcCos
2] « owner@ », « group@ » et « everyone@ » :
- « owner@ » semble être l’équivalent de « user » sur les droits unix ; donc le propriétaire d’un dataset
- « group@ » semble être l’équivalent de « group » sur les droits unix ; donc le groupe propriétaire d’un dataset
- « evenyone@ » n’a pas vraiment d’équivalent. Il peut s’apparenter à « others » sur les droits unix, mais il semble être plus large car lorsqu’il est défini, il semble également englober l’utilisateur propriétaire et le groupe propriétaire.
Sources :
https://www.truenas.com/community/threads/file-rights-acl-please-kill-me-now.91439/post-633456
https://www.truenas.com/community/threads/11-3-acl-management-explain-root-wheel-owner-group.81801/
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/gbchf/index.html
3] Vous pouvez vous apercevoir que tous les nouveaux utilisateurs sont automatiquement ajoutés au groupe « builtin_user ».
A ce sujet, inutile de créer des groupes « invités » ou « administrateurs », Truenas dispose maintenant de ces groupes génériques :
- builtin_users : groupe utilisateur qui regroupe tous les utilisateurs créés via l’interface web
- builtin_administrators : groupe administrateur
- builtin_guests : groupe invité
4] Notions :
- ACL du partage
- ACL du système de fichier
Lorsqu’on créé un partage SMB, par défaut, une « ACL de partage » de type [contrôle totale - autoriser- Everyone] est créée.
Sur cette page (https://www.truenas.com/community/t...e-between-smb-acls-and-filesystem-acls.90046/)
@anodos donne beaucoup d’information :
- Par exemple, il conseille de travailler avec l’ACL du système de fichier plutôt que d’utiliser l’ACL du partage.
- Il explique qu’on peut considérer les ACLs du partage comme les autorisations maximales possibles pour les groupes / utilisateurs.
(exemple : si l’ACL du partage est configuré en lecture seule pour tout le monde, alors quel que soient les autorisations définies sur les ACLs du système de fichier, tout le monde sera limité en lecture.)
A priori d’après ce même post, il est préférable de laisser « l’ACL de partage » définie par défaut par Truenas au moment de la création du partage SMB (donc : full control – allowed – Everyone).
Sécurité SMB
On trouve sur cette page de la documentation Truenas quelques conseils de sécurité (https://www.truenas.com/docs/solutions/optimizations/security/#smb) :
- ne pas utiliser SMB 1
- activer la signature du serveur :
Ayant posé la question sur le forum international (https://www.truenas.com/community/threads/smb-security-server-signing.106132/), il s'avère que la page de la documentation Truenas (donnée ci-dessus) n'est pas tout à fait à jour ou mal rédigé.
A priori, la signature est déjà intégré dans les protocoles SMB 2 et 3. Ce paramètre est donc inutile ici.
- ne pas activer l'authentification « NTLMv1 Auth » :
Cette option se trouve dans Services > SMB > cliquer sur « Configurer » (crayon) > paragraphe « NetBIOS » > case « NTLMv1 Auth »
- Paramétrage par défaut du partage recommandé :
Comme on peut le voir sur la capture d'image ci-dessous, ce paramètrage a activé certaines options et en a désactivé d'autres. De plus dans ce mode, la modification du paramétrage est bloqué.
On verra dans la suite des tests effectué dans ce post, qu'il nous faudra activer / désactiver la case « Activer les ACL ». Il faudra donc définir le champs « Objectif » sur « No presets » pour modifier le paramétrage par défaut.
Last edited: