effective les autorisations sont formées en combinant les autorisations réelles (réelles ?) avec le mask . Depuis le mask de votre fichier est rw- , tous les effective les permissions ont le x peu désactivé.
Réponse courte :si vous voulez un masque avec le bit d'exécution activé, vous devez le définir explicitement à l'aide de setfacl après touch . La sécurité interdit son paramétrage implicite.
setfacl -n -m m::rwx foo
"-n" pour supprimer le recalcul du masque (peut ne pas être nécessaire).
"m::rwx" définit la valeur du masque sur 'rwx'. Notez que "m ::x" désactiverait toutes les lectures et écritures.
Je suis incapable de montrer pourquoi le masque est "rw-". Je suppose que le répertoire par défaut où touch crée le fichier reste inchangé pour l'ensemble de l'exemple OP.
-
L'entrée de répertoire pour 'foo' doit afficher le propriétaire 'root' (à cause de la commande sudo et du groupe 'guards' car le répertoire a le bit SUID défini. Les autorisations seront par défaut '-rw-...r--' avec les autorisations de groupe du répertoire '-...r-x...' (en raison du bit SUID affiché en tant que petit s).
-
Vient ensuite l'ACLes, qui devrait être le répertoire par défaut. Étant donné que les ACL héritent, je ne m'attendrais pas à ce qu'aucune ACLe soit créée et que le masque ACLE soit le répertoire par défaut, 'rwx'.
Mais s'ils sont créés, je m'attendrais à ce que les nouveaux ACLe soient amorcés à partir de la valeur par défaut, laissant à nouveau le masque à 'rwx'. S'ils ne sont pas amorcés à partir des valeurs par défaut, cela semblerait contrecarrer l'idée d'une ACL par défaut - l'ACL "par défaut" ne fournirait qu'un utilisateur nommé et un groupe nommé ACLes.
Cela pose maintenant la question de savoir ce que devrait être le masque ACLe. Je m'attendrais à ce que ce soit 'rwx' à partir de l'entrée de masque par défaut. Mais il pourrait être créé avec un masque vierge, et alors toutes sortes de jargon juridique s'appliqueraient.
- Avec une ACL provisoire de user::rw-, group::r-x, other::r--, group:wheel:rwx, group:guards:rwx, and mask:::(unset), nous consultons le documentation pour
setfacl, en supposant que les mêmes règles s'appliquent à la création de fichiers.
Il y a une clause :
Si une ACL contient des entrées d'utilisateur nommé ou de groupe nommé et qu'aucune entrée de masque n'existe, une entrée de masque contenant les mêmes autorisations que l'entrée de groupe est créée.
Cela définirait le masque ACL sur "r-x", si l'entrée de groupe ACL a été créée à partir de l'entrée de répertoire de fichiers, ou sur "r-x" si l'entrée de groupe ACL provenait de l'ACL par défaut. (Autrement, dans ce cas, le résultat est le même.)
Il y a aussi une clause :
Si une ACL par défaut contient des entrées d'utilisateur nommé ou des entrées de groupe nommé et qu'aucune entrée de masque n'existe, une entrée de masque contenant les mêmes autorisations que l'entrée de groupe de l'ACL par défaut par défaut est ajoutée. ... les autorisations de l'entrée de masque sont encore ajustées pour inclure l'union de toutes les autorisations affectées par l'entrée de masque.
Si cette règle s'applique, le masque commencera par "r-x" (même logique) que la clause précédente), puis il sera ajusté pour être "l'union de toutes les autorisations affectées par l'entrée du masque".
"autorisations affectées par l'entrée de masque" n'est pas défini dans le setfacl documents de commande. La documentation POSIX ACL indique :
Le masque est la combinaison de toutes les autorisations d'accès du groupe propriétaire et de toutes les entrées d'utilisateur et de groupe.
Donnez le mot "union", qui est additif, je lirais "combinaison" comme étant un ou-ing logique. En d'autres termes, si un groupe ou un utilisateur ACLe a la permission "x", le masque contiendra "x".
- Par toute cette logique, la valeur du masque dans l'exemple de l'OP devrait être 'rwx', quel que soit le chemin logique suivi.
Le raisonnement ci-dessus doit être erroné, car le x pour exécuter n'apparaît pas dans le masque.
Par conséquent, il doit y avoir une règle sur la façon dont le masque est calculé qui a été "cachée" des sources de documentation courantes (ou nous avons trouvé un bogue).
Ma conclusion est que le 'x' est toujours supprimé sans condition et que la documentation est laxiste.
Cette modification a probablement été apportée sur la justification de la "sécurité" -- aucun fichier ne doit être implicitement exécutable, mais doit avoir le bit exécutable activé après sa création.