Claude (aka
Invité)
C'est quand même utiliser un bazooka pour tuer un moustique là…
«
Photoshop» : ça fait un gros
moustique
J'aime bien cette métaphore du parasite qui vient s'appliquer à un hôte pour pomper un peu de ses ressources. Un ironiste pourrait bien assimiler, en effet, la pullutation des « applications » informatiques à une nuée de tels insectes ailés, qui, sous couleur d'« aider » leur hôte (l'utilisateur), détournent une part croissante de son énergie spirituelle sur des domaines d'activité aussi factices qu'alambiqués.
Pourquoi ne pas récupérer l'idée précédente avec le seul "unmout" au lieu de "unmountDisk" ?
L'installateur d'«
El Capitan» greffe a priori un format
CoreStorage sur la partition de l'OS (ici le
/dev/disk0s2 du HDD). Ce qui implique un
Groupe de Volumes Logiques, dont l'instance sommitale (le
Volume Logique exporté) est identifiée comme un disque virtuel de second ordre par rapport au disque physique de premier ordre du HDD. Le HDD étant
/dev/disk0, le
Volume Logique du
CoreStorage est donc
/dev/disk1. En l'absence de tout chiffrement, une petite application de démontage se lançant à l'ouverture de session du «
Mavericks» du SSD devrait donc comporter l'instruction :
Bloc de code:
do shell script "diskutil umountDisk force /dev/disk1"
afin de démonter le
Volume Logique du
CoreStorage identifié comme
disk1 (
umount n'est pas une faute : c'est une graphie alternative de
unmount). J'ai fait l'essai en générant un
CoreStorage réversible non chiffré sur la partition de l'OS «
El Capitan» de mon SSD interne, et en démarrant sur le clone «
El Capitan» de mon SSD externe thunderbolt : l'instruction est honorée et le
Volume Logique, identifié à un disque virtuel de second ordre
disk1, démonté.
Ce
Volume Logique, dans un
CoreStorage, est un espace congruent bloc à bloc avec celui du
Volume Physique importé sur la partition de l'OS. Lorsqu'il y a
Chiffrement, seul l'espace de blocs du
Volume Physique est chiffré, et un logiciel "traducteur", utilisant l'algorithme d'une clé de déchiffrement, convertit bloc à bloc les signes chiffrés de cet espace en signes déchiffrés de l'espace du
Volume Logique. Le plan (déchiffré) du
Volume Logique sert à son tour de « point d'ancrage » (
dev node) au système de fichiers
JHFS+ de l'OS. Quand il n'y a
pas Chiffrement (=
blank CoreStorage), eh bien ! le dispositif formel est strictement le même : l'espace de blocs du
Physical Volume est "retraduit" dans l'espace de blocs congruent du
Logical Volume, sans qu'il y ait déchiffrement. C'est comme un interprète qui retraduirait un discours Français en... Français, càd. qui en restituerait un écho à l'identique ; alors que quand il y a chiffrement, l'interprète retraduit un discours Énigmatique en bon Français.
Ce petit discours destiné à montrer que, même si on ne lance pas un
Chiffrement via «
FileVault», le dispositif
CoreStorage greffé a priori sur la partition de l'OS par l'installateur d'«
El Capitan» (« à l'insu du plein gré » de l'utilisateur) est déjà intrinsèquement un facteur de complexité formelle considérable. Il y a déjà, en place une dualité d'espaces logiques : «
Volume Physique » (disque virtuel) / «
Volume Logique » (disque virtuel) et un mécanisme de "transposition logique" se trouve à l'œuvre, même si, en l'absence de chiffrement, il fonctionne « à vide ». On est de part en part dans de la virtualisation d'espaces logiques, avec un principe appariant 2 espaces virtuels :
Volume Physique / Volume Logique.
Tu me vois venir, en train de me faire l'« avocat du diable » (alors même que je déconstruis soigneusement sur mes disques tout dispositif
CoreStorage, personnellement parlant) ? - Quitte à subir la complexité d'un
CoreStorage, autant alors la virer au mode
Chiffrement, non pas pour "
protéger" dans le contexte présent les données du système de fichiers «
El Capitan» ancré dans le
Volume Logique ; mais pour "
verrouiller" ce volume au démarrage. Comme ça, le
Volume Logique ne monte pas automatiquement comme
disk1 : son espace logique n'est pas "généré", seul l'espace du
Volume Physique Chiffré se trouve présent à même la partition
/dev/disk0s2 du HDD, comme disque virtuel verrouillé.
À l'extrême limite même, l'option que je me suis amusé à proposer (
détourner le
Chiffrement FileVault de sa fonction de
protection des données vers une fonction de
non-montage automatique du volume impliqué) pourrait être considérée comme plus « simple » que celle du démontage. Car
démonter un volume (ou un disque de tous ses volumes) présuppose qu'il ait été
monté au préalable - ce qui donne une séquence :
montage automatique =>
démontage forcé. Alors qu'empêcher a priori un volume (ou un disque virtuel) de monter, si complexe que soit le procédé responsable de cette proscription, réduit la séquence précédente à...
zéro : il y a intrinsèquement
non-montage, un point c'est tout.
Pour ce qui est du problème éventuel d'un oubli du mot-de-passe authentifié permettant de déverrouiller le
Volume Logique bloqué par le
Chiffrement, bah ! il suffit que l'utilisateur
admin principal du «
Mavericks» du SSD externe et de l'«
El Capitan» du HDD interne ait la même
userID (nom et mot-de-passe), ce qui réduit déjà les chances d'oubli. Et de choisir comme mode de « secours » (en cas d'oubli), non pas l'option d'une clé alpha-numérique de déverrouillage auxiliaire (impossible à mémoriser et introuvable quand on en aurait besoin), mais celle du mot-de-passe
iCloud (= de l'
AppleID). En cas de 3 échecs de saisie d'un mot-de-passe authentifié à l'écran de déverrouillage du
Volume Logique Chiffré, un panneau proposera la saisie du mot-de-passe
iCloud, et si saisie valide, alors un nouveau panneau proposera une ré-initialisation du mot-de-passe de déverrouillage associé à l'utilisateur
admin. Je ne suis pas du tout sûr, par contre, que ce mot-de-passe de déverrouillage de l'écran initial puisse servir de mot-de-passe d'ouverture de session d'utilisateur...
