Enfant, j'affectionnais ces images dans lesquelles une figure de lièvre, par exemple, était dissimulée dans la masse d'un feuillage. Le défi était de repérer un détail dont le tracé n'était pas clos sur lui-même, mais appartenait à une ligne continue qu'il suffisait de suivre en esprit pour capturer le contour de l'animal. J'ai, par analogie, comme l'impression que le point de détail soulevé par r e m y lève un drôle de lièvre en fin de compte...
J'ai toujours apprécié, dans
Mac OS X, de pouvoir me livrer à des "bricolages intelligents" sur des composants du Système, par quoi j'entends changer certains paramètres pour induire des effets personnalisés non par tâtonnage à l'aveugle, mais par anticipation raisonnée (comme affecter, par exemple, un
SUID_bit à des exécutables permettant de les faire opérer directement en mode
root). La question posée par
r e m y :
Au passage, qu'elle peut donc être l'utilité de ces qtz et autres mov de cette première et large vire que tu m'indiquas ci-avant?
qui pointe les items
.qtz ou
.mov contenus dans le dossier :
/System/Library/Compositions m'a conduit à tenter d'en déplacer des copies dans le dossier connexe :
/System/Library/Screen Savers pour vérifier la conjecture suivante : peut-être s'agirait-il d'un "fond de réserve" dans lequel l'utilisateur averti pourrait aller piocher, pour en importer des doubles dans tel ou tel autre dossier-Système idoine afin que leur présence additionnelle vienne enrichir les fonctionalités qui en dépendent ? Ainsi, sous «
Yosemite 10.10.5» ou dans les bêta d'«
El Capitan», passer la nouvelle commande :
sudo trimforce enable, laquelle opère une simple copie depuis le dossier "ressources dormantes" :
/System/Library/Filesystems de la nouvelle extension du noyau
AppleDataSetManagement.kext dans le répertoire des
Extensions, permet(tait) le chargement au re-démarrage de cette
kext dédiée au
TRIM sur les SSD de tierce-partie.
Je me suis alors aperçu d'un drôle de truc : c'est que le dossier-Système «
Screen Savers » ne peut absolument pas être modifié par l'utilisateur sous «
El Capitan 10.10.0 [public release]», même en mode
root. Une conséquence du
SIP (me suis-je dit) : la nouvelle
System Integrity Protection qui injecte en
NVRAM un argument "
rootless=1", lequel, passé par l'
EFI au
kernel via le
boot_loader : boot.efi, affecte à une série de dossiers/fichiers-Système critiques un attribut_étendu d'immutabilité. Eh bien ! un re-démarrage sur la «
Recovery HD» pour passer la commande :
csrutil disable qui désactive le
SIP en
NVRAM, suivie de la commande de vérification :
csrutil status qui me renvoie bien un :
System Integrity Protection: disabled, après retour dans
OS X ne m'autorise toujours pas le moins du monde à écrire à l'espace du dossier-Système
Screen Savers le moindre élément.
Désactiver formellement le
SIP par l'utilitaire Apple
csrutil dédié ne permet donc pas de lever la totalité des restrictions nouvelles sur les dossiers critiques du Système. Aucune commande
root, aucune manipulation via la session graphique de l'utilisateur
root non plus, ne permet des modifications sur le dossier
Screen Savers. Non plus évidemment que sur le dossier
CoreServices. Ou
Extensions. Etc. Ils sont verrouillés absolument comme par un équivalent du
flag d'immutabilité_système :
schg. Ré-injecter spécifiquement en
NVRAM les arguments :
"rootless=0" &
"kext-dev-mode=1" ne permet pas non plus la moindre modification du dossier-Système
Extensions (je me disais : les développeurs doivent encore avoir le droit d'y injecter des extensions expérimentales, à fin de test - non ?). Fini aussi l'heureux temps des bidouilles sur le
boot_loader : boot.efi dont on pouvait désactiver l'original pour lui substituer un fichier customisé. Et, de fil en aiguille, qu'aperçois-je encore ? La commande :
sudo trimforce enable dont il fut fait moult réclame et qui marchait, après désactivation du
SIP, dans les bêta d'«
El Capitan»... n'est plus du tout validable dans le «
Terminal». Cette commande recopie normalement dans le dossier des
Extensions-Système un double de l'
Apple_kext AppleDataSetManagement.kext tenue en réserve dans le dossier des
Filesystems. Eh bien ! dans la version publique d'«
El Capitan», bernique ! Puisque le dossier des
Extensions est verrouillé comme en mode "immutabilité". Dans les faits, le
TRIM est a priori
activé à l'installation d'«
El Capitan» sur des SSD de tierce-partie parce que l'installateur a décelé la nature du disque au préalable et effectué la copie de la
kext a priori. Mais... le
TRIM n'est plus désactivable, car le dossier des
Extensions ne peut plus être purgé de l'
AppleDataSetManagement.kext. Qui n'est plus optative, mais automatique. Ajouterai-je qu'il est devenu impossible de greffer une
ACL utilisateur sur le moindre des dossiers/fichiers-Système précédemment évoqués, afin de se créer un petit passe-droit personnel (l'équivalent d'une "poterne d'entrée") ?
Bref, ce n'est pas un "
lièvre" enfantin que le point de détail de
r e m y m'a conduit à déceler dans l'arborescence du feuillage d'«
El Capitan», mais un de ces "
dogues de la porte" dont l'inscription "
cave canem" sur le carrelage avertissait chez les
Romains le visiteur de la présence. Un "
janitor" aussi redoutable que le chien
Cerbère. Un
Cerbère que la désactivation du
SIP ne renvoie nullement au chenil, mais convertit d'une fonction de barrage total, à un blocage ciblé. Exemple : le
SIP en place,
Cerbère interdit de modifier les
icônes des apps Apple ; le
SIP désactivé,
Cerbère permet cette customisation. Et aussi d'écrire à la
/Library. Mais pas aux dossiers critiques de la
/System/Library... Le chien
Cerbère avait 3 têtes : désactiver le
SIP muselle une de ces têtes, mais les autres gueules demeurent parfaitement vigilantes.
Et pourtant : il doit y avoir un truc... Car, par exemple, un logiciel comme «
DarkBoot.app» reste capable d'affecter le fichier du
boot_loader : boot.efi dans les
CoreServices (régulièrement verrouillées) pour qu'il charge un écran de
boot noir au lieu du gris par défaut. Ou encore : un logiciel comme «
cDock.app» est capable de customiser le
Dock, alors même que l'application relève encore du dossier verrouillé des
CoreServices. De même,
Mike Bombich qui se plaignait des restrictions introduites par le
SIP («
Carbon Copy Cloner» allait-il pouvoir toujours accéder en lecture en mode
root à tous les fichiers-Système, même les mieux protégés ? Un rétro-clonage incrémentiel d'un clone sur
OS X allait-il encore pouvoir encore s'envisager ?) - a l'air d'avoir heureusement neutralisé la menace des
3 têtes du
Cerbère.
☞ comme je viens tout juste, en simple
amateur que je suis, de déceler le
lièvre mâtin - je n'ai pas encore été
repasser dans «Pilote» (« mâtin, quel journal ! ») la méthode de l'inspecteur Bougrel pour m'aider à déceler le coupable chercher plus finement la
raison des effets... Ni
comment les suspendre : les développeurs agréés bénéficieraient-ils d'un privilège spécial ©Apple ? Qui se validerait comment si c'était le cas ?
[
r e m y me pardonnera d'avoir un tantinet "
jéopardizé" la droiture de son fil directeur par cette petite boucle filandreuse...]
r e m y
