Belle remontée de sujet après six mois de déréliction
-
Mais puisqu'on me tend sur une pelle à tarte une croutillante occasion de dissertation > alors autant gloser sur les points suivants :
- La traditionnelle réparation des "autorisations" dans l'«
Utilitaire de Disque»
old school (jusqu'à «
Yosemite 10.10» inclus) > lançait une commande du type :
Bloc de code:
diskutil repairPermissions /
Ce qu'il convient de noter > c'est que le domaine affecté par cette réparation était celui du
logiciel-Système (l'OS) abstraction faite des comptes d'utilisateurs. Pour ce faire > les permissions actuelles sur les fichiers du Système étaient comparées à un paradigme constitué par la collection des fichiers
.bom qui consignent (entre autre) les permissions originelles de ces fichiers à l'installation de l'OS.
- Cette fonctionnalité a été retirée de l'«
Utilitaire de Disque»
new school (à partir d'«
El Capitan 10.11») - ce qui revient à dire que le verbe
repairPermissions a été invalidé pour l'utilitaire
diskutil (la ressource de réparation des permissions-Système étant éliminée du
DiskManagement Framework). Elle était encore remplaçable par une commande du type :
Bloc de code:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
dans l'environnement d'«
El Capitan» > l'utilitaire
repair_packages rendant grosso modo le même service > mais cette commande ne fonctionne plus dans «
Sierra» > car l'utiitaire
repair_packages a été carrément retiré du dossier
/usr/libexec.
- Si l'on y réfléchit bien > il y a une logique derrière cet élagage : c'est qu'avec l'OS «
El Capitan 10.11», en effet, s'introduit le
SIP > protocole de sécurisation du Logiciel-Système qui, en gros, le verrouille dans ses rouages principaux à conformité avec sa configuration d'installation. En conséquence : à quoi rimerait de réparer des permissions sur des fichiers-Système verrouillés à conformité avec leur identité d'installation ? À rien. Sans compter que le
SIP verrouillant au démarrage lesdits fichiers-Système > ils sont in-modifiables dans leurs permissions > ce qui invalide
ipso facto la fonctionnalité traditionnelle de l'«
Utilitaire de Disque». Bref > c'est cohérent : permissions-Système intouchables > réparation hors de propos.
- Quant à la commande :
Bloc de code:
diskutil resetUserPermissions / `id -u`
(que l'on peut étendre en remplaçant le
`id -u` par l'identifiant numérique de l'utilisateur voulu :
501 >
503 etc. - voire en adressant un autre volume-Système que le volume
/ de l'OS démarré) - elle fait partie du lot des commandes non documentées dans le
man de
diskutil (avec sa comparse :
diskutil listUsers / - où le
/ peut être remplacé par n'importe quel volume-Système non-démarré - qui retourne la liste des utilisateurs de l'OS du volume-cible avec leurs identifiants numériques). La spécificité du verbe
resetUserPermissions > comme son intitulé l'annonce > consiste à ne réparer que les permissions du
dossier de départ de l'utilisateur ciblé (sans porter sur les fichiers du logiciel-Système comme l'ancienne fonctionnalité de réparation des permissions).
- Étant donné le caractère obsolète de la commande de réparation des permissions-Système > cette dernière commande "secrète" de restauration des permissions d'un dossier de départ d'utilisateur peut s'avérer utile. Car quel champ reste-t-il à l'utilisateur risque-tout pour ficher la pagaille > sinon l'espace de liberté privée qu'est son dossier
Home d'utilisateur ?
- 
à ce sujet : 
