Billet d'«Épistémologie Matutinale»
(néo-discipline au statut sujet à caution)
par l'impertinent
macomaniac
Salut
elRetard.
En simple
apostille verbeuse du commentaire de
bompi (qui a la légitimité
root en la matière) --> le fichier-Système hautement protégé
[parce qu'il paramètre les droits d'entrée au 'club' restreint des agents qui peuvent opérer en qualité de sudoer = 'substitut de root'] :
/private/etc/sudoers ne peut s'éditer '
unilatéralement' qu'en passant par la commande
visudo dans le «
Terminal». Passer par un éditeur de fichiers exogène (comme l'excellent «
TextWrangler» capable, après authentification 'admin' de l'initiataire, d'éditer les fichiers-Système d'
OSX) conduit comme tu t'en rends compte à la génération d'une 'doublette' : le fichier-Système
original est conservé
ipso facto sous l'intitulé dans ton cas de :
sudoers~orig, tandis que le fichier-édité est créé en parallèle sous le nom primitif :
sudoers.
Je vois dans cette itération d'écriture l'effet d'un 'mécanisme de défense' sagement implémenté par les ingénieurs de la Pomme afin de protéger l'intégrité du Système contre des bidouillages intempestifs. Tu te rends compte? Le logiciel exogène que tu as utilisé (genre «TextWrangler» donc) a vérifié au préalable ton habilitation parmi les sudoers d'après le fichier-Système du même nom, ce afin d'éditer le fichier en question : circularité logique que le Système 'admet' sur le mode du 'oui_mais_non' -si je puis dire- en générant un double_de_l'original (en archive du fichier primitif affectée du suffixe : ~orig) à côté du néo_fichier_édité sous l'intitulé simple inaugural.
À quoi bon ces dissertations d'âne bâté traînant laborieusement le fardeau d'une vaine rhétorique?
--> Eh bien! à exposer les
prémisses dont se déduit immédiatement la
conséquence adéquate : en cas de fausse manœuvre (ton cas...), le fichier valide est soigneusement conservé en 'doublette' sous l'intitulé de
sudoers~orig à côté du fichier invalide créé sous l'intitulé de
sudoers. Le cercle vicieux étant que le Système ne consulte en mode opératoire que le fichier intitulé :
sudoers (lequel est invalide), tandis que le fichier valide est inconsultable sous sa dénomination de
sudoers~orig --> il faut donc supprimer le fichier 'bidon'
sudoers, de manière à renommer le fichier valide
sudoers~orig en
sudoers, afin que le Système puisse consulter ce fichier afin de t'habiliter
sudoer à la demande. Sauf que, dans le «
Terminal» que tu cherches à utiliser à partir de ta session admin ouverte, pour ce faire il faut d'abord que tu puisses te prévaloir du statut de
sudoer pour re-nommer ledit fichier, ce que tu ne peux pas faire, puisque le fichier qui peut t'y authoriser (
sudoers~orig) est devenu inconsultable par le Système --> c'est ce qu'on appelle un «
circulus viciosus».
Pour le dénouer, il faut
donc que tu utilises un «
Terminal-de-root» :
- soit celui du mode Single User - d'usage abstrus, car non seulement le clavier logique est en QWERTY -ce qui est la moindre des difficultés- mais il faut commencer par monter l'ensemble des fichiers-Système par défaut en mode read_only en read_write afin que root, dans son «Terminal», puisse éditer les fichiers de /private/etc en supprimant (rm) le sudoers bidon et en re-nommant (mv) le sudoers~orig valide en sudoers. Pour ce faire, il faut toujours commencer en mode Single User par passer la commande :
et ↩︎ --> afin d'ajouter aux fichiers qui suivent le point de montage / la modalité 'writable' ;
- soit celui de la partition de récupération Recovery HD (que bompi te conseille judicieusement d'utiliser - s'il m'autorise cette acclamation déplacée) parce que le clavier logique est en AZERTY et surtout parce que les fichiers-Système de l'OS sont montés a priori en read_write pour le «Terminal» de root en tant que relevant d'un Volume_Logique monté a priori indépendamment du Volume_Logique de la Recovery HD. L'invite de commande dans le bash du «Terminal» de la Recovery : bash-3.2# est le synonyme strict de root# --> c'est donc un tapis rouge qui est déroulé pour
tout foutre en l'air réparer vertueusement les bourdes de l'utilisateur admin .
- en m'autorisant par avance de l'aimable aval de bompi (root du forum OSX dont je me pose ici audacieusement en sudoer au risque d'un déni d'authentification ), voici les commandes dans le «Terminal» de la Recovery HD susceptibles de régler la question de la doublette des fichiers :
-
et ↩︎ (touche 'Entrée' du clavier pour activer la commande) --> histoire de vérifier que le volume de l'OS est bien intitulé Macintosh HD - sinon, remplacer cette occurrence dans les commandes qui suivent par l'intitulé actuel du volume de l'OS renommé.
-
Bloc de code:
rm /Volumes/"Macintosh HD"/private/etc/sudoers
et ↩︎ --> pour supprimer le fichier qui porte le bon intitulé mais qui n'a pas le bon contenu (mettre entre "" l'intitulé de Macintosh HD afin d'en poser l'unicité nominale pour le Système).
-
Bloc de code:
mv /Volumes/"Macintosh HD"/private/etc/sudoers~orig /Volumes/"Macintosh HD"/private/etc/sudoers
et ↩︎ --> pour re-nommer le fichier qui a le bon contenu à l'intitulé primitif, le seul l'habilitant à être consulté par le Système pour l'authentification d'un membre du groupe admin comme sudoer à partir d'une session admin démarrée.
-
Bloc de code:
chown 0:0 /Volumes/"Macintosh HD"/private/etc/sudoers
et ↩︎ --> pour rétablir à root:wheel les accédants : user + group au cas où ce devrait être le cas (mais je ne le pense pas).
-
Bloc de code:
chmod 440 /Volumes/"Macintosh HD"/private/etc/sudoers
et ↩︎ --> dans la même veine (peut-être bien superflue) pour rétablir à read_only les permissions des accédants sur le fichier.
☞ une petite réparation des
permissions par '
acquis de conscience' dans l'«
Utilitaire de Disque» de la
Recovery HD et ... roulez jeunesse!
