Il est toujours bon de rappeler que dans bien des cas, un simple copier/coller à partir de la fenêtre d'information d'un dossier ou d'un volume (en effectuant cmd-i) sur la miniature de l'icône en haut de ladite fenêtre, fait l'affaire.

...pour nos libertés aussi c'est la peau de chagrin mon capitaine :-(

@aldomoco
Vous avez qu'à désactiver SIP définitivement. Moi je préfère être sécurisé.

@Stéphane Moussie (auteur de l'article).

Tu écris : «Le seul moyen de changer ces icônes est de désactiver SIP, mais on perd alors cette sécurité qui protège les fichiers systèmes».

Ta première proposition est exacte : les droits root sont rétablis sur tous les éléments du Système et «Litelcon» peut alors en bénéficier pour modifier des icônes d'éléments verrouillés en l'état sinon.

Ta deuxième proposition disons va un peu vite dans sa concision. Car rien n'empêche l'utilisateur de re-démarrer ensuite sur la «Recovery HD» et de réactiver le SIP => ainsi, la sécurité du Système sera de nouveau activée.

- pour ce qui est de la «faisabilité» : le SIP n'est pas sourcilleux quant à l'état du Système à reprotéger en ce qui concerne des changements d'icônes ou le logement de binaires tiers dans /bin, /sbin ou /usr) : il ne le vérifie pas ni ne le restaure, il le prend tel qu'il est donné et le conserve => donc il va accepter de verrouiller de nouveau l'état de choses comportant de simples icônes modifiées ou des binaires tiers.

- pour ce qui est de la «sécurité» : elle va de nouveau être active, en empêchant notamment toute nouvelle modification dans /System, /bin, /sbin et /usr (sauf /usr/local) à l'initiative directe de l'utilisateur ou par des paquets d'installation ; ou d'attacher au Système des processus genre déboguage ; ou encore d'injecter dans le noyau au démarrage des extensions non certifiées.

Intéressant macomaniac. Est-ce que c'est valable pour l'utilitaire qui active le trim pour les SSD non Apple ?

Je ne suis pas encore passé à El Capitan (ni à Yosemite d'ailleurs) sur mon Mac Mini mais il faudra bien que je le fasse et comme j'ai remplacé le disque poussif par un SSD ça m'intéresse.

Merci d'avance pour l'info.

Salut Hialmar

La commande : sudo trimforce enable (valide à partir de «Yosemite 10.10.4») invoque le néo-programme trimforce (at: /usr/bin) avec l'option "enable" et des droits root (sudo). Ledit "trimforce", à y regarder de près, est un script débile équivalant à la commande :

cp -a /System/Library/Filesystems/AppleDataSetManagement.kext /System/Library/Extensions

suivie d'un ordre de reboot. En quoi, si tu scrutes bien la commande cp, tu t'aperçois que la néo-extension Apple qui prend en charge le TRIM pour des SSD de tierce-partie pré-existe hors du dossier des Exensions, dans le dossier Filesystems de la /System/Library où elle a le statut de "paradigme inactif". La commande cp récursive déclenchée par le sudo trimforce enable consiste purement & simplement dans la création d'une copie du paradigme dans le dossier des Extensions, localisation qui, après reboot, rendra l'extension copiée active et donc le TRIM activé.

Dans ce contexte, ta demande : faut-il désactiver le SIP depuis la «Recovery HD» pour que la commande : sudo trimforce enable passe, se problématise ainsi : faut-il désactiver le SIP pour que le dossier "Extensions" de la Bibliothèque-Système puisse être modifié par l'import d'une copie de la AppleDataSetManagement.kext dont le paradigme réside dans le dossier collatéral des Filesystems ?

La logique voudrait que le réponse soit : OUI, s'il est vrai que le SIP verrouille contre toute modification (y compris en droits root) le répertoire /System (et donc récursivement son arborescence) par l'extended_attribute : com.apple.rootless... Donc un script débile de recopie avec sudo n'aurait aucune chance de pouvoir modifier le dossier des Extensions.

Eh bien ! Je ne sais pas si c'est parce que je suis en version 10.11.2_bêta, ou si Apple a changé son fusil d'épaule (il y a eu beaucoup de va-et-vient à ce sujet) => sudo trimforce enable passe le SIP actif, et même je peux m'amuser à copier des photos dans les Extensions !

[suite]

Je parle de "va-et-vient", parce que déjà dans certaines bêta d'«El Capitan 10.11.0» le programme csrutil (permettant de désactiver le SIP en NVRAM) était opérationnel depuis OS X (grâce à une application : «Configuration de sécurité.app»), application qui a ensuite été renvoyée aux utilitaires de la «Recovery HD», puis carrément supprimée (il faut donc passer un csrutil disable dans le «Terminal» de la «Recovery HD»).

Mais déjà, dans un autre fil, des membres de MacGé avaient signalé que la commande sudo trimforce enable passait sans désactivation du SIP au préalable, alors que normalement le SIP verrouille récursivement le répertoire /System contre toute modification. Et je viens ce matin de faire des tests : je peux à ma guise, via le Finder + mot-de-passe admin (donc l'équivalent de sudo dans le «Terminal») déplacer à la corbeille une extension hors du dossier /System/Library/Extensions ou inversement copier n'importe quel truc dedans : ça passe comme une lettre à la boîte [mais attention ! Je me suis bien gardé de re-démarrer dans ces conditions...].

Donc le SIP activé, le répertoire /System/Library/Extensions n'est pas verrouillé contre une intervention en mode root. L'utilisateur root aurait-il été repromu (conformément à son statut UNIXIEN) maître absolu du Système ? Ou bien, sachant qu'il va y avoir vérification d'intégrité des éléments du dossier Extensions on boot en cas de SIP activé, ce dossier a-t-il été spécialement exclu du verrouillage SIP ? - That is the question !

Salut macomaniac,

Merci beaucoup pour l'info.

J'essaierai ça quand je migrerai vers Yosemite ou EC.