Je visite rarement ce fil, peut-être parce que la déferlante initiale des plaintes consécutives à une installation précipitée de «Mavericks» m'a lassé, mais, lorsque j'aperçois la signature de François (
), j'augure une bonne occasion de m'instruire - ce qui est le cas ici.
♤
Le cas exposé par
sconie illustre l'adage : «
in minimo maxima» (de grandes choses enveloppées dans un détail). Son problème : ne pas pouvoir passer une commande
sudo dans le «
Terminal»
(je laisse de côté le but dans lequel il cherche à le faire : créer une clé-USB bootable de «Mavericks», soit par une invocation directe, soit par l'intermédiaire de «DiskmakerX» qui selon toute apparence invoque des droits 'sudo' pour ce faire), parce qu'un déni intervient dans le «
Terminal» justifié par le fait qu'aucune source afférente aux '
sudoers' n'est trouvée par le système.
Il est bon de savoir qu'un utilisateur-admin (obligatoirement) qui préfixe une commande par '
sudo' ne s'accorde pas directement à lui-même un 'super-droit' (un droit de 'Super-Administrateur' requis pour la passer, car les enjeux de modifications de données-système de la commande l'exigent) ; mais plus subtilement, il
demande le droit d'avoir ce droit au Système. Cette demande du 'droit d'avoir un super-droit' déclenche une vérification préalable par le Système : si, dans un fichier-texte hautement protégé situé à la racine de l'OS : le fichier '
sudoers', le demandeur est recensé comme faisant partie du club de ceux à qui on peut faire confiance pour exercer le 'super-droit' requis 'en bon père de famille'
. Si le demandeur ne fait pas partie du club (des admins, ici), mais n'est qu'un passant de l'espace de l'OS, le 'droit d'avoir le droit' va lui être dénié
illico.
Le problème de
sconie est que, faisant partie du club des 'admins', il a normalement ce 'droit d'avoir le droit' de passer une commande '
sudo', mais que, contre toute attente, le Système le lui refuse.
François, avec un laconisme énigmatique (heureusement assorti d'un manuel d'interprétation des énoncés
sibyllins) répond :
Car, comme tout un chacun l'aura déjà compris, la question est : pourquoi le Système prétend-il ne pas trouver la charte recensant les membres du club qui ont le droit d'avoir un super-droit dans le «
Terminal», alors que, dans un OS normalement constitué, le fichier '
sudoers' (qui est cette charte) est présent à l'adresse-racine :
/private/etc/ et réservé en
lecture à la personnification du Système (= '
root') et au groupe dont il est l'unique membre (= '
wheel'), c'est-à-dire en permissions :
-r--r----- (440 en valeurs octales)?
♧
Évidemment, si (pour une raison qui défie la raison) le fichier '
sudoers' n'existait pas à l'adresse susdite dans l'OS de
sconie, on aurait affaire à une explication radicale de l'échec à trouver la source des autorisations '
sudoers' : la disparition de la 'charte' dans son dépositoire. Je crois qu'une commande d'information-système mériterait d'être passée par
sconie dans le «
Terminal» (commande d'informations validable sans '
sudo', puisque se contentant de regarder sans toucher au Système) :
=> est-ce qu'au 'S' de l'ordre alphabétique des items listés, existe bien une ligne du type :
Bloc de code:
-r--r----- 1 root wheel sudoers
Si le «
Terminal» retourne que le fichier attendu n'est pas présent à l'adresse indiquée, la question est réglée : pas de charte, pas de 'droit d'avoir le super-droit' de passer des commandes en mode '
root'. Si le «
Terminal» retourne que le fichier attendu est présent avec les permissions réduites ci-dessus, on a la confirmation de la conjecture de
François (qui explique son
sibyllin :
chmod g+x /) est valide : ce n'est pas l'
absence de la charte qui fait que le Système n'arrive pas à la consulter pour valider la requête du 'droit d'avoir le droit' de l'utilisateur ; mais c'est son
inaccessibilité qui fait que le Système n'arrive pas à la consulter.
♡
La charte est contenue dans un sous-répertoire (= '
etc'), lui-même contenu dans un répertoire (= '
private') qui est posé dans l'espace-racine de l'OS. C'est dire si le chemin à parcourir par le Système pour accéder à la charte est court, car on ne quitte pas le 'saint des saints' ici. Mais chaque dossier dans OSX doit avoir, pour qu'on puisse l'ouvrir, une 'serrure' minimale non obturée : c'est l'«
executive bit» ('brin des permissions d'exécution'), marqué par la lettre '
x' (ou la valeur octale '
1' en 3è position). Le 'brin exécutif = 1' attaché aux permissions d'un répertoire signifie qu'il est possible d'«
exécuter l'accès» au contenu du répertoire, càd. d'y 'entrer' pour prendre connaissance de son 'contenu', à condition que le requérant fasse partie d'une au moins parmi les 3 catégories d'accédants possibles (le
propriétaire, le
groupe ou le
tout-venant) dotée d'un '
executive bit = 1'.
Lorsqu'un utilisateur-admin invoque le préfixe '
sudo' dans le «
Terminal», il demande donc au Système le 'droit d'avoir le droit' de passer une commande en mode '
root', en réponse de quoi le Système doit pouvoir
exécuter l'entrée successivement dans le répertoire '
private' et dans le sous-répertoire '
etc' afin de pouvoir lire la charte : '
sudoers' y recelée sur la consultation de laquelle il a seul (avec son groupe réservé) une 'carte de lecture'. Si jamais (pour une absconse raison) le '
brin exécutif = 1' n'était pas marqué (comme une 'étiquette') sur le répertoire '
private' non plus que sur le sous-répertoire '
etc' en association avec '
root' non plus qu'avec le groupe '
wheel', le Système ne pourrait pas 'exécuter l'entrée' dans ces répertoires (ouvrir ces valises) et la charte demeurerait inaccessible quoique '
root' en ait le privilège de lecture, comme un lecteur nanti d'une carte de lecture privilégiée des ouvrages de l'«
Enfer» qui ne pourrait pas exercer ce droit, parce que la pièce qui les contient serait fermée au public pour réfection.
♢
La commande qui a été proposée sur des sites de plaintes informatiques (
) et dont
François donne les adresses est donc :
à passer évidemment dans une session '
root' (une fois ce dernier activé dans une fonction d'utilisateur possédant une session graphique), sous peine de cercle vicieux : la nécessité dans toute autre session d'invoquer '
sudo' pour ce faire (enjeux système), alors que l'invocation '
sudo' est bloquée par l'inaccessibilité de la charte '
sudoers'.
Cette commande équivaut à une modification du mode (
change
mode) d'
une permission (
x = le 'brin exécutif = 1') attachée à
un accédant (
g = le groupe impliqué), ce concernant
tous les objets présents dans l'espace-racine de l'OS (= tout ce qui suit le point-de-montage logiciel '/' => tout ce qui est présent directement à partir de lui = espace-racine).
Nul doute qu'en passant cette commande, le '
brin exécutif =1' va être attaché, '
entre autres', au répertoire '
private' qui fait partie des objets présents dans l'espace-racine ; ainsi qu'aux '
liens symboliques' : '
⤻etc', '
⤻tmp' et '
⤻var' qui extrapolent (des plus curieusement) dans l'espace-racine de l'OS les 3 sous-répertoires majeurs du répertoire '
private' à côté de leur dossier d'inhérence, conférant par là en quelque sorte à des sous-ensembles un statut égalitaire de leur ensemble, dans la mesure où un
lien symbolique équivaut à la présence même de l'objet pointé à l'emplacement du pointeur, lequel n'a pas à proprement parler une 'existence de signifiant' distincte de son 'signifié'.
Apparemment, d'après les témoignages exubérants de guérison des plaignants, la commande évoquée 'marche' (en ce que, appendant au répertoire '
private' un '
brin exécutif =1' qui aurait fait défaut, le Système peut désormais 'exécuter l'entrée' dans ce répertoire et aller chercher la charte '
sudoers' dans le sous-répertoire '
etc'). Et donc
sconie pourrait se contenter, après avoir ouvert une session '
root', de la passer afin que 'passez muscades' : l'invocation 'sudo' désormais re-marche à partir d'une session-admin.
♖
Néanmoins, je trouve que cette commande appelle quelques remarques de la part du nommé
macomaniac (spécialiste à la binoculaire dans l'entomotomie des ailes de mouches dans le sens de l'épaisseur ) :
- Pourquoi diantre se borner à restaurer le 'brin exécutif =1' comme permission du groupe impliqué (= 'wheel' dont 'root' est seul membre), sachant que l'impossibilité préalable d'exécuter l'entrée aux répertoires d'inhérence de la charte 'sudoers', pour la lire, concernait tout autant le propriétaire légitime = 'root' que son groupe privilégié = 'wheel'? - Manifestement, la situation continue de boîter au niveau Système, l'executive bit de 'root' n'ayant pas été restauré sur le (ou les) répertoire(s) racine(s).
- Comment bigre le kernel au démarrage (qui exerce des droits 'root') peut-il parvenir à charger le BSD_Unix, sachant qu'il a besoin pour ce faire d'exécuter l'entrée aux sous-répertoires de 'private' : 'etc', 'tmp' et 'var', si le 'brin exécutif =1' n'est pas attribué à 'root' sur le répertoire 'private'? Je crois que j'ai la réponse à ma question : le kernel court-circuite l'exécution de l'entrée de 'private', en suivant à la place les liens symboliques : '⤻etc', '⤻tmp' et '⤻var' aux sous-répertoires. Alors que, lors d'une invocation 'sudo' dans le «Terminal», le Système doit suivre le chemin à 'private' dans l'ignorance des liens symboliques (sans quoi nécessairement l'accès à la charte 'sudoers' serait possible, dès lors même que le kernel a pu démarrer le Système en suivant les liens symboliques CQFD.).
- Les liens symboliques 'etc', 'tmp' et 'var' portent alors bien le 'brin exécutif =1' appendu au propriétaire ('root') et au groupe ('wheel'), sans quoi ils seraient bloqués. Mais s'il est vrai qu'un lien symbolique vaut pour l'objet qu'il pointe, ses droits valent-ils pour ceux de l'objet qu'il pointe? La commande : chmod g+x / nécessairement le suppose, puisqu'elle se borne à restaurer le 'brin exécutif =1' sur le répertoire 'private' et pas sur le sous-répertoire 'etc' (n'étant pas récursive), supposant donc que le sous-répertoire 'etc' porte un 'brin exécutif' correct (= 1) pour 'root' et 'wheel' dès lors que le kernel a pu démarrer l'OS en suivant le lien symbolique pointant 'etc' pour en exécuter l'entrée.
- N'est-ce pas abusif d'étendre le privilège du 'brin exécutif = 1' pour le groupe de référence à tous les objets présents dans l'espace-racine, sachant qu'à côté de répertoires-système où le 'brin exécutif' signifie la possibilité d'exécuter l'entrée au répertoire, la commande va affecter des fichiers invisibles de cet espace-racine qui ne sont pas des exécutables ('binaires'), alors même que le 'brin exécutif', en ce qui concerne des fichiers, n'est pertinent que pour des exécutables et doit être absent sur des non-exécutables? Ainsi, le fichier .DS_Store présent dans l'espace-racine va se retrouver doté d'un 'brin exécutif = 1' (=> 674 : -rw-rwxr--), alors qu'il devrait être en : 664 = -rw-rw-r--.
♘
☞ ma curiosité serait immensément soulagée (
) si
sconie acceptait de passer dans le «
Terminal» les 2 commandes de simple information suivantes et d'en poster les résultats (avant ré-installation de son système) :
&
ce, afin d'avoir la preuve (ou non) d'une absence du '
brin exécutif = 1' sur le répertoire '
private' et de sa présence sur le sous-répertoire '
etc'.
☞ les ruminations ci-dessus me laissent penser en définitive qu'une ré-installation du Système est la manière la plus commode d'apurer le monde des droits sur l'OS de
sconie.
♔
