Outils de développement · Calculatrice Chmod
ACL POSIX vs bits du mode chmod : quand rwx ne suffit pas
· Contexte
chmod unix contrôle d'accès
Les bits de mode couvrent un propriétaire, un groupe et tous les autres. Cet article explique le modèle ACL POSIX.1e qui comble le vide, comment il interagit avec chmod et quand un groupe partagé reste la réponse la plus simple.
Un lecteur de plus que ce que le modèle permet : un fichier appartient au groupe d'applications et un auditeur extérieur au groupe doit le lire
Le modèle en mode ordinaire n'a pas de quatrième emplacement d'identité. Il peut décrire les autorisations d'un propriétaire, d'un groupe et de tous les autres, mais il ne peut pas nommer un auditeur supplémentaire. La calculatrice reflète exactement cette limite : sa matrice, son affichage symbolique et ses résumés exposent ces trois classes ainsi que des bits spéciaux, et non des entrées d'accès par utilisateur ou par groupe.
Élargir l'autre classe simplement pour accueillir un lecteur supplémentaire affecterait chaque identité entrant dans cette classe. La calculatrice peut afficher ce changement arithmétique, comme le passage de 0640 à 0644, mais elle ne peut pas décider si un accès plus large est acceptable. L'accès nommé nécessite des preuves et des outils en dehors de cette route.
La limite de trois classes – pourquoi le modèle traditionnel a exactement un emplacement pour le propriétaire, le groupe et les autres
Chaque chiffre octal final appartient à une classe fixe. Le propriétaire, le groupe et les autres reçoivent des indicateurs de lecture, d'écriture et d'exécution, produisant neuf positions ordinaires. Le modèle ne peut pas insérer un autre triplet pour une personne nommée. Une conversion réussie décrit donc fidèlement le mode de base sans rien dire sur les entrées supplémentaires attachées ailleurs.
Cette limitation est importante lors de la lecture d'une sortie apparemment restrictive. Une valeur symbolique de rw-r----- vous indique le propriétaire de base, le groupe et les autres bits représentés par 0640. Cela ne prouve pas qu’aucune autre identité ne puisse lire l’objet, car le calculateur n’inspecte pas les données ACL ni n’observe aucune couche d’application externe.
POSIX.1e ACL - entrées d'utilisateur nommé et de groupe nommé ajoutées au même fichier, définies avec setfacl et lues avec getfacl
Les entrées d'utilisateur nommé et de groupe nommé ne sont pas implémentées. La source ne contient aucun analyseur ni formateur pour les enregistrements ACL, aucun masque ACL et aucune opération setfacl ou getfacl. Ces concepts peuvent motiver l'utilisation d'un mécanisme de contrôle d'accès externe, mais cet article ne peut pas spécifier la syntaxe ou le comportement des commandes au-delà de la reconnaissance des limites explicites de la calculatrice.
Gardez le mode de base visible tout en effectuant ce travail séparé. Entrez la valeur octale signalée, vérifiez le propriétaire, le groupe et les autres triples, et enregistrez tout bit spécial. Utilisez ensuite une documentation faisant autorité sur le système de fichiers et des outils externes appropriés pour les entrées nommées. L'aperçu chmod généré par la calculatrice ne crée, n'inspecte ni ne conserve d'ACL.
Les entrées ACL nommées nécessitent des outils externes non implémentés ici
La relation entre un changement chmod, des bits de classe de groupe et un masque ACL dépend d'un comportement non implémenté ici. La calculatrice convertit simplement un mode douze bits et émet une affectation ou un argument octal. Il ne dispose pas d'un état ACL par rapport auquel calculer les droits effectifs, il ne peut donc pas prévoir si une entrée nommée sera plafonnée.
Évitez de décrire une conséquence ACL à partir de la seule sortie de mode. Un changement de 0640 à 0600 supprime manifestement les trois bits de classe de groupe dans ce modèle ; tout ce qui concerne les utilisateurs nommés, les groupes nommés ou les masques nécessite les règles réelles de l'ACL et de la plate-forme. Vérifiez ceux-ci avec la documentation du système de fichiers avant d'appliquer la commande affichée à un objet portant une ACL.
L'interaction du masque ACL avec chmod nécessite une documentation sur le système de fichiers
L'héritage ACL par défaut se situe également au-delà de la route. La page n'a aucune entrée ACL de répertoire, aucune opération de création et aucun champ umask. Basculer le sélecteur de cible du fichier au répertoire modifie les verbes en anglais simple attachés à un mode fixe ; il ne crée pas de fichier, d'héritage de modèle et ne calcule pas les autorisations d'un futur objet.
Pour la même raison, un mode répertoire actuel ne peut pas prédire le mode de chaque nouveau enfant ici. La calculatrice peut expliquer que la lecture, l'écriture et l'exécution du répertoire correspondent au listage, à la modification des entrées et à l'accès au contenu nommé. Il ne peut pas combiner ces bits de base avec des entrées par défaut, des demandes de création ou des masques de processus qu'il ne reçoit jamais.
L'héritage ACL par défaut et l'interaction umask sont en dehors de cette route
Considérez un mode de base fourni de 0640 pour un fichier pouvant nécessiter un lecteur supplémentaire. La calculatrice affiche rw-r----- : lecture et écriture du propriétaire, lecture de groupe, autre aucun. C'est la déclaration complète soutenue par ses entrées. Il n'identifie pas l'auditeur et ne propose pas non plus une quatrième classe dans laquelle placer cette identité.
Conservez cet enregistrement en mode de base pendant que le travail ACL s'effectue ailleurs. Si le processus externe signale ultérieurement un mode différent, décodez-le à nouveau et comparez chaque classe. Ne collez pas de commande ACL dans le champ mode et ne supposez pas que l'aperçu de la commande intègre des entrées nommées. Il représente toujours uniquement le mode numérique actuellement affiché.
Exemple concret : garder le mode de base lisible pendant que le travail ACL se déroule ailleurs
Les autres familles d'ACL, les règles de système de fichiers distants et la prise en charge du montage ne sont pas établies par ces sources. La calculatrice ne détecte pas le type de stockage, les options montées, le système d'exploitation ou la disponibilité des opérations ACL. Une vue ACL manquante constitue donc une limite d'implémentation et non une preuve que l'objet sous-jacent ne dispose pas de contrôles d'accès plus riches.
La politique obligatoire, les capacités, la propriété et l'identité du processus sont également distinctes. Même une connaissance complète du mode de base ne peut pas remplacer ces entrées. Signalez la conversion de mode comme une seule couche et étiquetez explicitement chaque couche non observée. Cela évite qu’un affichage rwx propre ne soit confondu avec une analyse d’autorisation complète.
Les autres modèles d'ACL et la prise en charge du montage ne sont pas déduits
Lorsque trois classes suffisent, le calculateur en donne un compte précis et réversible. Lorsqu'ils ne le sont pas, gardez ce compte de base lisible plutôt que de forcer une exception nommée dans l'autre classe. Les vues octales, symboliques et de case à cocher doivent correspondre aux mêmes valeurs de propriétaire, de groupe, autre et de bit spécial.
La règle d'arrêt est simple : utilisez cette route pour l'arithmétique en mode de base et les outils externes faisant autorité pour l'état des ACL. Ne déduisez jamais les entrées nommées, les masques, l'héritage ou la prise en charge du système de fichiers à partir de rwx uniquement. Un examen minutieux combine ces sources de preuves distinctes sans prétendre que le calculateur implémente des structures de contrôle d'accès que son code source ne contient pas.