Quelles relations lient le masque ACL et l'autorisation de groupe standard sur un fichier?

Au début, je crée un fichier et vérifie qu'il s'agit des autorisations standard et des entrées ACL:

$ touch file; ls -l file; getfacl file
-rw-r--r-- 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
other::r--

Ensuite, je définis le masque ACL sur le fichier et vérifie à nouveau ses autorisations standard et ses entrées ACL:

$ setfacl -m mask:rwx file
$ ls -l file; getfacl file
-rw-rwxr--+ 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

Notez que la permission de groupe standard du masque ACL sur le fichier a également changé.

1. Quelle connexion existe-t-il entre le masque ACL et l'autorisation de groupe standard?
2. Quelle est la raison du couplage des autorisations de masque ACL et de groupe de fichiers? Quelle logique se cache derrière cela?

Les distributions en question sont Debian Linux 7.6 et CentOS 7

ÉDITER

À ce stade, je voulais juste partager certaines de mes conclusions que j'ai trouvées tout en recherchant les relations entre les autorisations de groupe de fichiers standard et le masque ACL. Voici les observations empiriques que j'ai trouvées:

1. Le masque ACL peut être modifié:

   1. en le définissant directement avec la setfacl -m m:<perms>commande;
   2. en modifiant les autorisations de groupe de fichiers avec la chmodcommande (si le masque ACL est déjà présent; il peut ne pas être présent car il est facultatif s'il n'y a pas d'autorisations ACL d'utilisateur ou de groupe nommées sur le fichier);
   3. en ajoutant une entrée ACL d'utilisateur ou de groupe nommé (le masque sera automatiquement recalculé).

2. Le masque appliquera des droits d'accès maximum (s'il y a des entrées ACL avec des autorisations présentes qui dépassent les autorisations du masque ACL) uniquement si le masque est défini directement par setfacl ou par modification de l'autorisation de groupe de fichiers avec chmod (non calculé automatiquement). Toutes les modifications apportées aux entrées ACL déclencheront le recalcul automatique du masque ACL et désactiveront effectivement le "mode d'application".

3. Il existe quelques effets secondaires affectant implicitement les autorisations de groupe de fichiers standard lors de l'utilisation des ACL:

   1. Une entrée ACL d'utilisateur ou de groupe nommé appliquée à un fichier peut modifier le masque ACL (augmenter ses autorisations) et donc les autorisations de groupe de fichiers effectives. Par exemple, si vous, en tant que propriétaire du fichier, disposez d'autorisations "rw-r - r-- jim étudiants" et que vous accordez également l'autorisation rw à l'utilisateur "jack", vous accorderez également implicitement des autorisations rw à quiconque du groupe "étudiants".
   2. Un masque ACL plus strict (moins d'autorisations) peut supprimer définitivement les autorisations de groupe de fichiers standard correspondantes. Par exemple, si vous avez un fichier avec des autorisations de groupe de fichiers standard rw et que vous appliquez un masque ACL en lecture seule au fichier, ses autorisations de groupe passeront en lecture seule. Ensuite, si vous supprimez toutes les entrées ACL étendues (avec la setfacl -bcommande), les autorisations de groupe resteront en lecture seule. Cela s'applique uniquement au masque ACL plus strict, le masque ACL plus doux (plus d'autorisations) ne modifie pas définitivement l'autorisation du groupe de fichiers d'origine après sa suppression.

Cela n'a pas de sens si les autorisations du fichier Unix ne correspondent pas à l'entrée acl et vice versa. En conséquence, la page de manuel ( acl(5)) indique ce que vous demandez:

CORRESPONDANCE ENTRE LES ENTRÉES ACL ET LES BITS D'AUTORISATION DE FICHIER

Les autorisations définies par les ACL sont un surensemble des autorisations spécifiées par les bits d'autorisation de fichier.

Il existe une correspondance entre le propriétaire du fichier, le groupe et d'autres autorisations et des entrées ACL spécifiques: les autorisations du propriétaire correspondent aux autorisations de l'entrée ACL_USER_OBJ. Si l'ACL a une entrée ACL_MASK, les autorisations de groupe correspondent aux autorisations de l'entrée ACL_MASK. Sinon, si l'ACL n'a pas d'entrée ACL_MASK, les autorisations de groupe correspondent aux autorisations de l'entrée ACL_GROUP_OBJ. Les autres autorisations correspondent aux autorisations de l'entrée ACL_OTHER_OBJ.

Le propriétaire du fichier, le groupe et les autres autorisations correspondent toujours aux autorisations de l'entrée ACL correspondante. La modification des bits d'autorisation de fichier entraîne la modification des entrées ACL associées, et la modification de ces entrées ACL entraîne la modification des bits d'autorisation de fichier.

Addendum en réponse à la discussion:

Quelle est la raison du couplage des autorisations de masque ACL et de groupe de fichiers? Quelle logique se cache derrière cela?

Une bonne explication est ici . En substance, le masque est un

[...] limite supérieure des autorisations accordées à toute entrée de la classe de groupe.

Cette propriété de limite supérieure garantit que les applications POSIX.1 qui ne connaissent pas les ACL ne commenceront pas soudainement et de manière inattendue à accorder des autorisations supplémentaires une fois les ACL prises en charge.

Dans les ACL minimales, les autorisations de classe de groupe sont identiques aux autorisations de groupe propriétaire. Dans les listes de contrôle d'accès étendues, la classe de groupe peut contenir des entrées pour des utilisateurs ou des groupes supplémentaires. Cela entraîne un problème: certaines de ces entrées supplémentaires peuvent contenir des autorisations qui ne sont pas contenues dans l'entrée de groupe propriétaire, de sorte que les autorisations d'entrée de groupe propriétaire peuvent différer des autorisations de classe de groupe.

Ce problème est résolu grâce à la saisie du masque. Avec des listes de contrôle d'accès minimales, les autorisations de classe de groupe sont mappées aux autorisations d'entrée de groupe propriétaire. Avec les listes de contrôle d'accès étendues, les autorisations de classe de groupe sont mappées aux autorisations d'entrée de masque, tandis que l'entrée de groupe propriétaire définit toujours les autorisations de groupe propriétaire. Le mappage des autorisations de classe de groupe n'est plus constant.

J'ai finalement compris ce qui se passait exactement quand j'ai vu ce lien Gestion des ACL

Plus précisément, ces masques remplacent et fonctionnent essentiellement pour remplacer NAMED USER et toutes les autorisations GROUP. Cela signifie que si vous:

1. ajustez le masque, vous modifiez les autorisations max du groupe,
2. si vous modifiez l'une des autorisations de groupe avec un masque présent, le masque prend les autorisations de groupe max de toutes les autorisations de groupe
3. les autorisations de lecture, d'écriture et d'exécution de groupe sont déterminées en fonction du masque, le cas échéant

J'espère que cela aide.

Quelle logique se cache derrière cela?

La logique est complètement brisée et donc les ACL POSIX sont des bêtises pures et inutiles.

S'ils visaient à préserver la compatibilité avec les applications qui n'ont pas la notion d'ACL, à l'exception du modèle "ugo" UNIX primitif standard , elles ont en fait échoué au début, car maintenant, chaque application qui efface les autorisations de groupe retire effectivement l'accès ajouté par les ACL.