Ce que je trouve (personnellement) stimulant pour l'intelligence, en informatique, ce sont les petites anomalies de fonctionnement logique. Quand tout fonctionne sans anicroches, en effet, on nage dans cette béatitude qui, d'après
Jean-Jacques Rousseau, entretient l'imbécillité heureuse ; quand, inversement, le Système tout entier plante (par exemple au démarrage), c'est une vague de désespoir total qui submerge le jugement. Mais quand il ne s'agit que d'anomalies logiques, c'est-à-dire de petits désagréments récurrents, alors l'entendement, sans se départir de sa sérénité, peut s'interroger sur la « raison des effets ».
Lorsque
Robert demande :
Bloc de code:
sudo chmod -R -N /chemin d'accès/nom_repertoire
fonctionne, tu peux m'expliquer l'action de cette commande ?
je pense qu'on est dans le cas de figure que je viens d'évoquer. L'anomalie était qu'en tant qu'utilisateur dénommé
toto il ne pouvait ni renommer ni supprimer des fichiers contenus dans des dossiers dont
toto (= lui-même) était le propriétaire (
user) avec des permissions de
lecture / écriture / exécution, ce qui paraissait paradoxal, puisque la permission d'écriture implique en principe le pouvoir de modifier un intitulé de fichier, voire de le supprimer en tant qu'objet, dans l'espace d'un dossier. La résolution de cette inhibition de permissions paradoxale a consisté en une commande de de vidage des listes
ACL associées aux objets logiques concernés. Ce qui appelle des éclaircissements.
--------------------
D'abord concernant la forme de la commande :
Bloc de code:
sudo chmod -R -N /chemin d'accès/nom_repertoire
=> on a affaire à une commande appelant
sudo (pour opérer en droits
root de
System Administrator) et l'exécutable
chmod (
change_mode) qui permet de manipuler les permissions associées aux accédants de tel ou tel objet logique (dossier ou fichier). L'option
-R ajoute une portée récursive à l'action, en étendant son effet d'un dossier parent pris pour objet, à toute la profondeur de son contenu enfant (de sous-dossiers et/ou de fichiers). L'option
-N introduit une spécificité négative à la commande
chmod, équivalant à : vider les listes
ACL associées à tous les objets ciblés de leur contenu d'
ACE.
--------------------
Ce qui appelle un prolongement explicatif de la signification de ces acronymes.
ACL =
Access Control List : "Liste de Contrôle d'Accès". Les liens donnés par
Jean 
permettent de se faire une idée succincte de la chose. Une liste
ACL se trouve associée a priori à tout objet logique (dossier ou fichier) dans OS X, liste qui ne comporte aucune entrée (liste vide ou
blank) d'ordinaire, mais peut comporter des entrées spéciales par une décision d'administration : il s'agit alors d'
ACE =
Access Control Entries : "Entrées de Contrôle d'Accès", qui consistent à affecter des permissions « granulaires » à tel ou tel accédant (utilisateur ou groupe) déjà en poste (l'utilisateur, le groupe principal ou le groupe secondaire =
everyone de l'objet), soit surajouté (un autre utilisateur ou un autre groupe).
Ces permissions sont « granulaires », au sens où elles sont plus finement ciblées que les 3 grandes permissions « carrées » ou « massives » de lecture / écriture / exécution qui sont les permissions
POSIX (autant dire basiques). Il peut s'agir de :
- delete Supprimer l’élément. La suppression peut être accordée soit par cette autorisation sur un objet ou le droit delete_child sur le répertoire contenant.
- readattr Lire un objet attributs de base. Ce qui est implicitement accordée si l’objet peut être regardé et ne sont pas explicitement nié.
- writeattr Ecrire attributs de base d’un objet.
- readextattr Read extended attributes.
- writeextattr Lire les attributs étendus.
- readsecurity Lire les informations de sécurité d’un objet étendue (ACL).
- writesecurity Écrire des informations sur la sécurité d’un objet (propriété, mode, ACL).
- chown Modifier la propriété d’un objet.
Autorisations spécifiques aux répertoires :
- list afficher le contenu.
- search Rechercher des fichiers par leur nom.
- add_file Ajouter un fichier.
- add_subdirectory Ajouter un sous-répertoire.
- delete_child Suppression d’un objet contenu. Voir la permission suppression des fichiers ci-dessus.
Autorisations pour tout autre fichier (non répertoire) :
- read Ouvrir en lecture.
- write Ouvrir en écriture.
- append Ajouter Ouvre en écriture, mais d’une manière qui ne permet d’écrire que dans des zones du fichier ne sont pas déjà écrites.
- execute Exécutez le fichier comme un script ou un programme.
=> supposons par exemple que dans l'OS de
Robert il y ait en plus de
toto (= lui), un utilisateur
bibi : sur un dossier dont l'
user en
lecture / écriture / exécution est
toto ; on pourrait imaginer de créer une
ACE en faveur de
bibi par une commande du type :
Bloc de code:
sudo chmod -R +a "bibi allow read,write,execute,delete,readattr" /chemin d'accès/nom_repertoire
=>
bibi se trouverait ainsi investi d'un droit de co-propriété récursive en
lecture / écriture / exécution sur le dossier + des permissions de
détruire et lire les
attributs_étendus.
Comme le signale un des fils données par
Jean, ce type d'attributions supplétives permet de créer, entre les accédants
POSIX en poste et les hors-accès, des « accédants hybrides » (ou des intermédiaires) qui possèdent un droit d'accès modulaire à tel ou tel objet logique. Cas de figure qui peut s'avérer souhaitable dans des situations de foules d'utilisateurs d'un même Système, comme en entreprise, où des Administrateurs du Système peuvent juger utile de promouvoir modulairement tel ou tel accédant a priori hors-poste d'accès à des privilèges granulaires. Par contre, à l'échelle d'un Mac utilisé en mode purement individuel, voire avec 2 sessions alternatives dans un usage familial, recourir à l'introduction d'
ACE granulaires dans les
ACL d'objets logiques paraît quelque chose d'incongru.
--------------------
Ce petit discours que je viens de tenir ressemble trait pour trait à ces importations mécaniques d'informations que favorise tant l'internet : parti d'un questionnement suscité par une anomalie expérimentale, on va s'informer sur
Wikipedia d'un quelconque mécanisme informatique et... on se figure que d'avoir replacé le cas expérimental sous l'autorité d'une règle logique, le problème en est résolu.
Eh bien ! en ce qui concerne l'anomalie évoquée dans ce fil, il n'en est rien justement, si l'on ne confond pas description d'un mécanisme logique et explication d'un paradoxe. Le problème de
Robert est qu'il devait renseigner son mot-de-passe d'utilisateur
admin toto pour exercer... ses droits
POSIX réguliers d'user (et d'abuser) en
lecture / écriture / exécution d'un dossier (impliquant son contenu de fichiers), càd. de propriétaire régulier. Vider les listes d'
ACL associées à ces objets de leurs entrées d'
ACE a restauré sa faculté de manipuler les fichiers impliqués sans devoir donner son mot-de-passe
admin. Ce qui soulève une QUESTION : pourquoi donc l'existence d'
ACE dans les
ACL des dossiers concernés introduisait-elle une limitation des permissions plénières de
toto sur ces objets ?
La théorie des
ACL / ACE nous a appris qu'il s'agissait de promouvoir supplémentairement des accédants à des permissions granulaires, afin d'introduire des privilèges intermédiaires dans un fonctionnement multi-utilisateurs. Pourquoi donc ce raffinement censé apporter un «
plus » introduit-il un «
moins » en ce qui concerne ici le propriétaire en exercice
toto ? Voilà ce que les exposés cités éludent et qui équivaut à un PARADOXE majeur des
ACL : un
apport de droits supplémentaires qui implique une
restriction corrélative des droits des accédants en poste, en les obligeant à s'authentifier pour... exécuter les droits qu'ils détiennent réglementairement.
--------------------
Intrigué par ce paradoxe des
ACL, j'avais creusé cette question notamment dans le fil suivant : ☞
Modifier le propriétaire d'un dossier - Maverick☜ => pour ne pas rallonger la « sauce » ici, je vais me contenter d'en reprendre la substance.
Une
ACE (entrée de contrôle d'accès) introduite dans une
ACL (liste d'autorisations granulaires associée à un objet) peut avoir 2
valeurs :
positive (ajout) vs
négative (restriction). Ces valeurs n'ont pas les mêmes implications quant aux droits des accédants
POSIX en poste : lorsqu'on a affaire à des
ACE positives (ajout d'un co-propriétaire, ajout d'un accédant autorisé à lire etc.), alors la règle : « qui peut le plus, peut le moins » s'applique => cet ajout
positif n'introduit aucune limitation quant à l'exercice des permissions plénières de lecture / écriture /exécution de l'
user (
toto ici). Car « plus par plus » (+
x +) ne fait jamais « moins » (-).
Il en va tout autrement lorsque l'
ACE inroduite dans une
ACL a une
valeur négative (restriction). Imaginons pour simplifier que le groupe secondaire en poste (
everyone =
other = n'importe qui) associé à un dossier dont l'
user est
toto ne possède aucune permission
POSIX sur le dossier
--- (pas de lecture, pas d'écriture, pas d'exécution). Cette absence de permissions
POSIX de base n'est pas une
négation de droit, c'est une
absence de droit.
Everyone n'est pas marqué «
interdit de ceci » dans une liste noire ;
everyone est simplement «
dépourvu d'accrédition d'accès » à telle ou telle chose. Par exemple, dans une entreprise, je n'ai pas le code d'accès électronique permettant d'ouvrir la porte d'une salle : cette « absence d'accréditation » n'est en aucune façon ma « nomination dans une liste noire comme interdit d'accès ». Je ne suis pas «
interdit d'accès », parce que je n'ai pas le code ; je suis «
incapable d'accès ». Mon incapacité n'est pas une interdiction nominale. Je suis ignoré dans cette incapacité même
(telle est la clé du bonheur des simples : ils sont « ignorés » nominativement d'un Système dans leur incapacité).
Si, au contraire, une
ACE à
valeur négative se trouve intégrée à une liste
ACL sur un objet, il s'agit-là d'une «
interdiction nominative » : c'est d'une « liste noire » dont nous sommes en train de parler. Si l'
ACE négative en question consiste en un
« everyone deny delete » (n'importe est frappé d'interdiction de destruction), alors un « effet récursif » intervient sur le fonctionnement des privilèges des accédants en poste : pour ce qui est de la permission («
delete » ici) nominativement interdite à tel ou tel, l'
user même (qui a le privilège de « détruire ») ne peut plus
exercer ce droit plénier, sans faire la
preuve juridique aux yeux du Système qu'il a bien la
légitimité d'exercer ce droit. En renseignant un mot-de-passe.
Interdire nominativement quelque chose à quelqu'un, dans le cadre d'un Système informatique (et pas seulement laisser quelqu'un dans un état d'
incapacité), c'est fatalement
obliger récursivement les privilégiés à
prouver leurs droits correspondants. Càd. à réitérer juridiquement l'attestation de leur privilège. Car, juridiquement parlant, avant même d'être des privilégiés, ils sont des n'importe qui. Un privilégié est un n'importe qui nanti d'un privilège. Si un seul n'importe qui se trouve interdit a priori d'un privilège, et pas simplement «in-nanti» d'un privilège, alors tout privilégié, en tant que n'importe qui doté d'un privilège, doit administrer la preuve qu'il n'est pas que le n'importe qui qu'il est (auquel cas, il serait lui
aussi interdit de privilège), mais qu'il détient l'attestation de droit de son privilège. Un Système formel, comme un Système informatique, a les mêmes contradictions qu'un Système sociétaire. Interdire un droit à autrui oblige, récursivement, à administrer la preuve du droit qu'on possède.
Vider une liste d'
ACL de ses
ACE, ce qui supprime les
ACE négatives (aussi bien que les
positives éventuelles), libère donc les accédants privilégiés en poste de l'obligation de faire la preuve de leurs droits au coup par coup ...
--------------------
