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

Au début, je crée un file et vérifie ses permissions standard et ses inputs 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 place le masque ACL sur le file et vérifie à nouveau qu'il s'agit d'permissions standard et d'inputs 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 qu'avec l'autorisation du groupe standard de masques ACL sur le file a également changé.

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

Les dissortingbutions en question sont Debian Linux 7.6 et CentOS 7


MODIFIER

À ce stade, je voulais juste partager quelques conclusions de la mine que j'ai trouvé lors de la search sur les relations entre les permissions de groupe de files standard et le masque ACL. Voici les observations empiriques que j'ai trouvées:

  1. Le masque ACL peut être changé:

    1. en le réglant directement avec la command setfacl -mm:<perms> ;
    2. en modifiant les permissions du groupe de files avec la command chmod (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'permissions d'ACL sur le file);
    3. en ajoutant soit l'user nommé, soit l'input ACL de groupe (le masque sera automatiquement recalculé).
  2. Le masque appliquera les droits d'access maximum (s'il existe des inputs ACL dont les permissions dépassent les permissions de masque ACL) uniquement si le masque est défini directement par setfacl ou par modification de l'autorisation de groupe de files avec chmod (non calculé automatiquement). Toute modification apscope aux inputs ACL triggersra le recalcul automatique du masque ACL et désactivera efficacement le «mode d'application».

  3. Il existe un certain nombre d'effets secondaires qui affectent implicitement les permissions de groupe de files standard lors de l'utilisation des lists de contrôle d'access:

    1. L'input d'ACL d'un user ou d'un groupe nommé appliquée à un file peut modifier le masque ACL (augmenter ses permissions) et donc les permissions de groupe de files effectives. Par exemple, si vous possédez les droits "rw-r-r-jim students" en tant que propriétaire du file et que vous accordez également l'autorisation rw à l'user "jack", vous accordez implicitement des droits rw à n'importe qui du groupe "étudiants".
    2. Le masque ACL plus ssortingct (less d'permissions) peut supprimer définitivement les permissions de groupe de files standard correspondantes. Par exemple, si vous disposez d'un file avec les permissions de groupe de files rw standard et que vous appliquez un masque ACL en lecture seule au file, les permissions de groupe diminuent en lecture seule. Ensuite, si vous supprimez toutes les inputs ACL étendues (avec la command setfacl -b ), les permissions de groupe restront en lecture seule. Cela s'applique uniquement au masque ACL plus ssortingct, le masque ACL plus souple (plus d'permissions) ne modifie pas de façon permanente l'autorisation du groupe de files d'origine après sa suppression.

Cela n'a aucun sens si les permissions de file unix sont en désaccord avec l'input acl et vice versa. En conséquence, la page de manuel ( acl(5) ) dit ce que vous requestz:

CORRESPONDANCE ENTRE LES ENTRÉES ACL ET LES BITS DE PERMISSION DE FICHIER

Les permissions définies par les ACL sont un sur-set des permissions spécifiées par les bits d'autorisation de file.

Il existe une correspondance entre le propriétaire du file, le groupe et les autres permissions et les inputs ACL spécifiques: les permissions du propriétaire correspondent aux permissions de l'input ACL_USER_OBJ. Si l'ACL possède une input ACL_MASK, les permissions de groupe correspondent aux permissions de l'input ACL_MASK. Sinon, si la list de contrôle d'access n'a pas d'input ACL_MASK, les permissions de groupe correspondent aux permissions de l'input ACL_GROUP_OBJ. Les autres permissions correspondent aux permissions de l'input ACL_OTHER_OBJ.

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

Addendum en réponse à la discussion:

Quelle est la raison du couplage du masque de masque ACL et des permissions de groupe de files? Quelle logique se cache derrière?

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

[…] limite supérieure des permissions que toute input de la class de groupe accordera.

Cette propriété de binding supérieure garantit que les applications POSIX.1 qui ne sont pas au courant des ACL ne commenceront pas soudainement et inopinément à accorder des permissions supplémentaires une fois que les ACL sont sockets en charge.

Dans les ACL minimales, les permissions de class de groupe sont identiques aux permissions de groupe propriétaire. Dans les ACL étendues, la class de groupe peut contenir des inputs pour des users ou des groupes supplémentaires. Cela entraîne un problème: certaines de ces inputs supplémentaires peuvent contenir des permissions qui ne sont pas contenues dans l'input de groupe propriétaire, de sorte que les permissions d'input de groupe propriétaire peuvent différer des permissions de class de groupe.

Ce problème est résolu par la vertu de l'input du masque. Avec des lists de contrôle d'access minimales, les permissions de class de groupe correspondent aux permissions d'input de groupe propriétaire. Avec les ACL étendues, les permissions de class de groupe correspondent aux permissions d'input de masque, tandis que l'input de groupe propriétaire définit toujours les permissions de groupe propriétaire. Le mappage des permissions de class de groupe n'est plus constant.