Mes contributions précédentes dans ce fil avaient eu (disons) un caractère tout « théorique » sans portée « pratique ». Il est vrai (n'en déplaise aux participants de ce fil avides de toucher les « fruits » de leur « action »
) que : présence ou absence d'une icône d'
Utilisateur Invité à l'écran de
login préliminaire du démarrage, à me supposer dans le cas de figure d'une activation de principe de «
FileVault» - je m'en « tamponne le coquillard », en toute franchise, en tant que souci d'ordre « pratique » (disgrâce visuelle à l'écran de
login et addition d'un geste supplémentaire de sélection de l'utilisateur dont il faut renseigner le mot-de-passe).
Mais ce n'est pas parce qu'un problème m'indiffère dans sa portée « pratique » qu'il ne m'interpelle pas au plan « théorique ». Parce qu'il est question de
chiffrement par «
FileVault» ici, et qui dit «
FileVault», dit génération d'un format
CoreStorage sur la partition de l'OS. Or le
CoreStorage est un objet si singulier que tout ce qui le concerne pique mon intérêt (conformément à cet
aggiornamento de la maxime humaniste : « je suis
formaliste, et rien de ce qui touche au
format CoreStorage ne m'est étranger »...).
J'ai donc été amené à m'intéresser ce matin à cette question de l'«
Utilisateur Invité » uniquement en tant qu'
indice, ou
symptôme, d'une problématique sous-jacente plus générale.
--------------------
Que se passe-t-il quand on démarre un Mac dont le volume-Système n'est
pas chiffré par «
FileVault» ? L'
EFI lit en
NVRAM le
PATH à la partition de
boot, exécute le
boot_loader at:
/System/Library/CoreServices/boot.efi et ce dernier charge le
prelinkedkernel at:
/System/Library/PrelinkedKernels/prelinkedkernel. Le
kernel démarré, les
kexts chargées, lance le processus
launchd dont, après chargement du Système d'
OS X, un service domestique (
opendirectoryd) visite la localisation:
/private/var/db/dslocal/nodes/Default/users de manière à charger les fichiers
.plist des utilisateurs et par là permettre au processus
LoginWindow d'afficher à l'écran d'ouverture de session les icônes ad-hoc d'utilisateurs.
Un fichier
Guest.plist fait partie du lot des
plist et il est possible de faire l'expérience amusante suivante : le fichier ouvert par «
TextWrangler» et en parallèle le panneau des
Préférences Système/Utilisateurs et groupes (cadenas déverrouillé), sélectionner l'
Utilisateur invité et cocher en regard la case : "
Autoriser les invités à se connecter à cet ordinateur" affecte immédiatement en écriture en mode "
live" le fichier
Guest.plist au niveau de la clé :
<key>passwd</key>, en ce qui concerne la chaîne associée qui devient :
<string>********</string> ; alors que décocher le même case dans le panneau des
Utilisateurs et groupes édite en mode "
live" la chaîne à :
<string>*</string>.
L'
opendirectoryd charge donc l'identité de l'
Utilisateur Invité avec la valeur "
Activé" vs "
Désactivé" selon que la chaîne du mot-de-passe est "
pleine" ou "
vide", et le
LoginWindow relaie cette donne en "
Affichant" vs "
Masquant" l'icône d'
Utilisateur Invité à l'ouverture de session.
--------------------
Que se passe-t-il à présent lorsque l'activation de «
FileVault» a
chiffré le volume de l'OS ? Un format
CoreStorage a été intercalé entre la partition support du disque et le système de fichiers
jhfs+ de l'OS. Format impliquant la (ré)génération d'un
Volume Logique à partir d'un
Volume Physique émulant un disque dur à la seule condition que la
Famille de Volumes Logiques médiatrice réceptionne un mot-de-passe habilité à opérer le
déverrouillage du
Volume Logique et par là son montage par activation du traducteur des
blocks chiffrés en
blocks déchiffrés induisant le chargement du système de fichiers d'
OS X.
La conséquence en est qu'au moment du
boot le système de fichiers de l'OS, inclus dans le
Volume Logique verrouillé, est totalement inaccessible. Donc le fichier
boot_loader : boot.efi autant que le
prelinkedkernel. Et bien évidemment le fichier
Guest.plist at:
/private/var/db/dslocal/nodes/Default/users. Et aucun service
opendirectoryd n'est lançable non plus pour l'afficher. J'en ai d'ailleurs opéré la contre-vérification : «
FileVault» activé, si je manipule depuis ma session ouverte, dans le panneau des
Utilisateurs et groupes, la case : "
Autoriser les invités à se connecter à cet ordinateur" en regard de l'
Utilisateur Invité => aucun modification en écriture du fichier
Guest.plist ne s'opère plus comme en cas de volume
non-chiffré (comme il était logique de l'attendre).
--------------------
Allora qué pasa ?
Pour rendre accessible le
Volume Logique verrouillé de l'OS, il faut qu'un écran de
login puisse être affiché au
début du
boot, et non à la
fin (après chargement du Système) en cas de
non-chiffrement - ce afin que le renseignement d'un mot-de-passe permettre de
déverrouiller le volume.
Il faut donc qu'un démarrage puisse s'enclencher en l'absence de toute ressource logicielle disponible du volume de l'OS
verrouillé. J'avais fait état dans mes messages antérieurs de ce fil de la solution trouvée à ce paradoxe par les ingénieurs de la : faire en sorte que l'
EFI lise en
NVRAM un
PATH de
boot au volume connexe de la «
Recovery HD»,
non-verrouillé et donc montable automatiquement, afin d'exécuter son
boot_loader boot.efi de rechange en initialisation du
boot sur le disque.
Je m'étais précédemment arrêté à cette trouvaille, sans creuser le processus plus finement. Car la question se pose : le
boot_loader boot.efi de la «
Recovery HD», intrinsèquement, ne doit pas être modifié dans son code, s'il doit pouvoir servir aussi bien au
boot de la partition de récupération qu'à l'enclenchement du démarrage d'
OS X par affichage d'un écran de
déverrouillage. Et cet écran : d'où il le sort alors, le
boot.efi (pas d'une poche kangourou) ?
Eh bien ! je viens de m'apercevoir ce matin que, lorsqu'on active «
FileVault» et après que le Mac ait re-démarré en préambule de cette tâche, un
nouveau dossier se trouve créé sur la partition de la «
Recovery HD». Le dossier de démarrage de la «
Recovery HD» (contenant le
boot_loader boot.efi) est le
com.apple.recovery.boot. Dossier que je présume intouché. Mais un autre dossier se trouve alors créé à côté après l'activation de «
FileVault» : le dossier
com.apple.boot.P (contre-test : la désactivation de «
FileVault» conduit à la suppression au re-démarrage inaugural de ce dossier
com.apple.boot.P de la partition de la «
Recovery HD»).
De quoi se compose ce dossier :
com.apple.boot.P ? De l'arborescence suivante :
com.apple.boot.P/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations - dernier dossier recelant 12 fichiers porteurs de l'extension
.efires =>
appleLogo.efires,
battery.efires,
disk_passwordUI.efires,
flag_picker.efires,
guest_userUI.efires,
loginui.efires,
Lucida13.efires,
Lucida13White.efires,
preferences.efires,
sound.efires,
unknown_userUI.efires.
Les fichiers de format
.efires désignent des fichiers "
ressources de l'EFI" (
EFI_res) dont on pourrait considérer, qu'après les
flags chargés à partir de la
NVRAM, ils constituent des
instructions de boot mises en cache sur la partition de la «
Recovery HD» que l'
EFI charge
avant même d'exécuter le
boot_loader : boot.efi de la récupération. Ayant chargé ces instructions
a priori d'après les
.efires_files, l'
EFI les injecte à l'exécution au
boot_loader : boot.efi de la «
Recovery HD». Ce dernier "sait" donc à partir de là quels sont les
loginui (les
Users_Identities de
login), les
disk_passwordUI (les
Users_passwords de déverrouillage de disque), les
preferences (
préférences de boot) etc.
et, en particulier, le
guest_userUI (l'
User_Identity de l'Invité). Sans compter les ressources du fond d'écran - j'en passe et des meilleures...
--------------------
"Dopé" intellectuellement par cette trouvaille mineure (en terme d'«
onto_logie générative »), je me suis demandé : oui, mais comment se trouve créé ce dossier d'instructions spécifiques de démarrage passées par l'
EFI au
boot_loader auxiliaire
boot.efi de la «
Recovery HD» en cas de
chiffrement du volume de l'OS ? Je n'ai pas été long à suivre le fil : il existe dans
OS X un dossier
paradigme (modèle ou
archè) at:
/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations => comportant les mêmes exacts 12 fichiers
.efires que l'on retrouve dans le dossier de
boot auxiliaire
com.apple.boot.P de la «
Recovery HD».
Voici comment je reconstruis la séquence : à l'activation de «
FileVault», les fichiers
.efires de l'OS at:
/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations se trouvent édités (notamment en ce qui concerne les utilisateurs habilités à déverrouiller le volume
chiffré par leur mot-de-passe + l'activation ou non de l'
Utilisateur Invité - ce, en lieu et place de l'édition des fichiers
plist at:
/private/var/db/dslocal/nodes/Default/users qui sont édités en cas de
non-chiffrement pour toute manipulation du panneau des
Utilisateurs et groupes. Ces fichiers
.efires édités dans le dossier
Caches d'
OS X servent de
paradigme à une opération de
recopie avant re-démarrage sur la partition de la «
Recovery HD» dont le volume se trouve monté, de manière à générer le dossier d'instructions de
boot auxiliaires de l'
EFI :
com.apple.boot.P à passer spécifiquement au
boot_loader boot.efi de la récupération afin qu'il affiche un écran de
déverrouillage ad-hoc du volume
chiffré.
--------------------
Eh bien ! Je subodore que sur certains Macs et dans certaines configurations de l'OS, le travail initial d'édition des fichiers
.efires at:
/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations initié par les manipulations graphiques de l'utilisateur dans les panneaux
Sécurité et confidentialité/FileVault +
Utilisateurs et groupes/Utilisateur Invité reste inopérant sur le fichier paradigme :
guest_userUI.efires => en suite de quoi, sa copie inéditée est effectuée dans le dossier d'instructions auxiliaires
com.apple.boot.P de la «
Recovery HD». Je dis : sur certains Macs etc., car ayant
chiffré expérimentalement ce matin le volume de mon OS «
El Capitan - 10.11.3 (2è version bêta)», je n'ai rencontré aucune difficulté, en cochant / décochant la case des
Utilisateurs et groupes/Utilisateur Invité => "Autoriser les invités à se connecter à cet ordinateur" à obtenir par effet direct l'affichage ou le masquage au re-démarrage d'un
Utilisateur Invité à l'écran de
déverrouillage.
Donc dans mon OS, le fichier
guest_userUI.efires a bien été directement édité dans les
Caches du Système, et par suite, recopié avant re-démarrage tel quel dans le dossier
Caches de démarrage du
com.apple.boot.P de la «
Recovery HD». Mais si la lecture ou la manipulation d'un fichier
.plist ne me pose aucun problème logique ; il n'en va pas de même d'un fichier au format
.efires qui est en code. Car je ne suis absolument pas informaticien et donc le langage de code m'est absolument étranger. Je ne peux donc pas en dire plus sur ce qu'il conviendrait éventuellement d'éditer dans le code de ce fichier pour que l'
Utilisateur Invité soit
non-affiché à l'écran de
déverrouillage en cas de
chiffrement «
FileVault».
[La raison qui fait que l'édition du fichier
guest_userUI.efires plante ou non à la manipulation de la case :
Utilisateurs et groupes/Utilisateur Invité => "
Autoriser les invités à se connecter à cet ordinateur" en cas d'activation de «
FileVault» m'échappe tout autant...]
--------------------
: c'est ton insistance « pratique » qui m'a forcé à trouver une « théorie » qui marche... Sinon : cet affichage résilient de l'Utilisateur Invité à l'écran de déverrouillage quand «FileVault» est activé, je n'y aurais vu qu'un détail négligeable et je me serais contenté d'une « déclaration d'ignorance » (cf. mon message #22).
