Personnellement parlant (càd. envisagé à mon échelle d'utilisateur et d'utilisation) : c'est le type de nouvelle dont je me bats l'œil (pour ne pas dire : me tamponne le coquillard).
Parce qu'au fond c'est mon imagination seule qui se trouve aiguillonnée : on lui demande d'envisager qu'un malandrin fantôme pourrait faire irruption dans mon domicile, en tombant par chance sur mon ordinateur allumé et ma session ouverte sans verrouillage d'écran en cas de mise-en-sommeil, pour aller tripoter les préférences-Système de mon OS. Bien curieux ce malandrin : il aurait à sa disposition l'espace de ma session avec mes données en accès libre mais la seule chose qui lui importerait, serait d'aller déverrouiller le panneau des Utilisateurs et groupes grâce à un bogue de root. Et pour faire quoi ? Pour se créer un compte personnel ? Lui permettant de modifier des réglages de l'OS ?
Comme ce scénario n'est qu'une mise-en-scène imaginaire (je le répète : à mon échelle d'utilisateur et d'utilisation - vu qu'aucun malandrin ne viendra s'immiscer dans ma session ouverte à tous les vents dans l'espace de mon domicile) - je dois dire que je n'« éprouve » rien de spécial en lisant ce genre de nouvelles. Et n'étant donc en proie à aucune combinaison d'imagination et de sentiment, je garde une parfaite neutralité d'esprit.
La seule chose qui serait intéressante, serait de se demander « théoriquement » quel fonctionnement logique permet de déverrouiller le panneau des Utilisateurs et groupes avec la saisie seule du nomcourt (
root) du
System Administrator sans accompagnement d'un mot-de-passe.
----------
Le Super-Administrateur
existe pour le Système, en cela comme tous les autres utilisateurs personnels, parce qu'il possède une
carte d'identité à son nom dans la base de données des utilisateurs de l'
Open Directory (le service d'annuaire des utilisateurs). Cette base de données est le sous-dossier localisé at:
/private/var/db/dslocal/nodes/Default/users. Ce sous-dossier
users ne doit pas être confondu avec le répertoire
/Users des comptes d'utilisateurs. Car dans
users il n'y a que des fichiers
plist définissant des
existences d'utilisateurs pour le Système. Par exemple, supposons qu'un utilisateur
toto existe, il n'existe pour le Système que parce qu'un fichier
toto.plist (at:
/private/var/db/dslocal/nodes /Default/users/toto.plist) le fait exister logiquement. Il en va de même pour
root de ce point de vue :
root n'existe logiquement comme utilisateur pour le Système, que parce qu'il existe un fichier "carte-d'identité"
root.plist at:
/private/var/db/dslocal/nodes/Default/users/root.plist.
Dans un fichier
plist d'utilisateur, il y a une série de clés (ou rubriques) dont voici un résumé :
gid (groupe d'appartenance) >
home (adresse du dossier de compte d'ouverture de session) >
jpegphoto (icône de login) >
realname (Nom Complet ou Long Name) >
name (Nom de Compte ou Short Name) >
shell (
/bin/bash par défaut) >
uid (
501 si 1er admin ;
0 si root). Une de ces clés est :
passwd (mot-de-passe) qui peut se trouver associée à
deux valeurs possibles (dans la chaîne associée à la clé) -->
soit :
Bloc de code:
<key>passwd</key>
<array>
<string>********</string>
</array>
si un mot-de-passe
existe pour l'utilisateur ;
soit :
Bloc de code:
<key>passwd</key>
<array>
<string>*</string>
</array>
si aucun mot-de-passe
n'existe pas pour l'utilisateur.
Il s'agit ici de désignations symboliques d'
existence ou de
non-existence d'un mot-de-passe - aucun mot-de-passe n'étant stocké en tant que tel dans un fichier plist d'identité d'utilisateur.
Par défaut > dans le fichier
root.plist la situation est la suivante :
Bloc de code:
<key>passwd</key>
<array>
<string>*</string>
</array>
càd. qu'
aucun mot-de-passe ne se trouve défini pour l'utilisateur
root.
Voici un bref aperçu de la carte d'identité
root.plist :
gid =
0 (groupe
wheel) >
uid =
0 >
home =
/private/var/root (dossier de compte) >
realname =
System Administrator >
name =
root >
shell =
/bin/sh >
passwd =
* (pas de mot-de-passe).
Il s'ensuit que l'utilisateur
root existe a priori pour le Système sans mot-de-passe (
*) --> la seule différence introduite par la définition d'un mot-de-passe pour
root (
********) étant la possibilité d'
ouvrir une session graphique sur le dossier de compte localisé at :
/private/var/root.
root ne se trouve donc nullement "
activé" en tant qu'
utilisateur par la définition d'un mot-de-passe > puisque
root existe de par un fichier
plist d'utilisateur indépendamment d'un mot-de-passe inexistant par défaut (
*). La seule chose qu'active la définition d'un mot-de-passe
root (
********) est la
possibilité d'ouverture d'une session graphique sur le dossier de compte de
root at:
/private/var/root. Et par extension la possibilité de
renseigner une identité d'utilisateur graphique dans des panneaux d'authentification affichés par le
Finder. C'est donc un
avatar d'utilisateur graphique de
root qui se trouve activé avec la définition d'un mot-de-passe
root.
Il est évident que lorsqu'un panneau d'authentification est affiché par le
Finder > le nom et le mot-de-passe renseignés sont comparés par le Système aux paradigmes du fichier
plist de l'utilisateur. En cas d'astérisque simple
* à la clé
passwd dans le fichier
plist - comme c'est le cas par défaut pour
root - càd.
absence de mot-de-passe > le Système doit retourner un
échec d'authentification.
Il serait intéressant ici que des ingénieurs informaticiens (ce que je ne suis pas) expliquent en quoi le protocole de vérification du Système s'est trouvé pris en défaut par un bogue dans
High Sierra > en ne retournant pas un
échec d'authentification en cas de
non saisie d'un mot-de-passe (blanc) pour le nom
root, alors même que dans le fichier
root.plist ce n'est
pas un
mot-de-passe vide existant qui se trouve a priori défini > mais une
absence de mot-de-passe (
*). Ce qui n'est pas le même chose.
----------
Pour terminer par un peu de technique :
Une commande
Bloc de code:
sudo defaults read /private/var/db/dslocal/nodes/Default/users/root.plist passwd
lit la valeur actuellement associée à la clé
passwd dans le fichier
root.plist. Si elle retourne un :
c'est qu'un mot-de-passe d'utilisateur graphique a été
défini pour
root ; si elle retourne un :
c'est qu'
aucun mot-de-passe d'utilisateur graphique n'est actuellement
défini pour
root (situation par défaut).
Pour quelqu'un qui veut définir un mot-de-passe d'utilisateur graphique pour
root > l'utilitaire spécialisé à cette fin est
dsenableroot (
directory_service_enable_root : habiliter
root dans le service d'annuaire). Voici la syntaxe de la commande :
Bloc de code:
dsenableroot -u username -p userpassword -r rootpassword
- l'option -u (user = utilisateur) étant accompagnée de la saisie du nomcourt ou nomdecompte de l'utilisateur > l'option -p (password ou mot-de-passe) étant accompagnée de la saisie de son mot-de-passe (privilège admin requis) > l'option -r (root) étant accompagnée de la saisie du mot-de-passe choisi pour root. Tout s'affichant en clair à l'écran.
Exemple : supposons un utilisateur (admin) dont le
nomcourt (ou nom de compte) soit
toto > et dont le
mot-de-passe soit
toto > et que ce
toto veuille définir pour
root un
mot-de-passe qui soit également
root --> la commande devient :
Bloc de code:
dsenableroot -u toto -p toto -r root
toto devra renseigner
en aveugle son mot-de-passe
toto > et la validation de la commande est confirmée par :
Bloc de code:
dsenableroot:: ***Successfully enabled root user.
