la réparation des autorisations lancée depuis une autre session administrateur créée pour l'occasion, restaure egalement sur ce dossier Applications le quadruplet d'autorisations spéciales pour l'user remy (et pas pour le nouvel administrateur "test" cree pour l'occasion)
Disons que c'est cohérent avec ce qu'on peut conjecturer : à savoir > à l'installation d'on ne sait quoi, une instruction de greffer une multiple
ACE "
remy allow ---" sur le répertoire
Applications a été appliquée et elle s'est trouvée archivée dans un fichier
.bom d'un dossier
Receipts > lorsqu'un utilisateur quelconque - serait-il
root depuis sa session graphique d'utilisateur - lance une réparation des permissions dans l'«
Utilitaire de Disque» > ce dernier passe la commande
diskutil repairPermissions / > laquelle active la commande
[sudo] /usr/libexec/repair_packages --repair --standard-pkg / (car
diskutil est un "wrapper" : un enveloppeur de sous-commandes) --> donc l'utilitaire
repair_packages va lire des fichiers
.bom de reçus des paquets d'install à la localisation des
standard-pkg et il y trouve quelque part inscrite l'instruction d'une
ACE multiple en faveur de
remy > donc il la recolle en mode "réparation" si elle manquait...
J'ai noté un petit point curieux (mais qui ne peut pas jouer dans l'affaire) : l'utilisateur
remy est
503, alors que l'
admin aborigène est normalement
501 > le résultat d'une suppression de compte
admin primitif et de promotion d'un compte
remy secondaire au rang princeps (
remy ayant récupéré un Mac familial pour son usage) ? Ou bien y a-t-il encore un utilisateur
501 autre que
remy ?
En furetant un peu ce matin, je me suis aperçu que la commande informative :
Bloc de code:
/usr/libexec/repair_packages --list-standard-pkgs /
retourne la liste des paquets d'installation "Logiciel_Apple_Standard" dans le volume démarré. Si tu la passes, tu te rendras compte qu'il ne s'agit pas d'installation de logiciels particuliers, mais de paquets_Système : le
pkg cardinal étant le
com.apple.pkg.Essentials (et c'est le fichier
.bom y recelé qui comporte tout le toutim concernant les applications Apple) > à côté, tu as les
pkg des mises-à-jour Système successives [dans «
Yosemite», les
pkg sont archivés at:
/Library/Receipts et il y a exportation de fichiers de reçus at:
/private/var/db/receipts > ça n'arrête pas de changer selon les OS).
La commande ci-dessus échappe les
pkg d'install de logiciels non-Apple (ou non-Système) > aussi une commande :
Bloc de code:
pkgutil --pkgs --volume /
est-elle beaucoup plus complète dans son retour, car intégrant les logiciels tiers (
pkgutil est le véritable utilitaire des paquets installés - impliquant les permissions afférantes).
Une fois repéré le rôle cardinal du
com.apple.pkg.Essentials > une commande :
Bloc de code:
sudo pkgutil --repair com.apple.pkg.Essentials
lance la réparation de tous les composants-Système d'après le paradigme du fichier
.bom recelé dans le
com.apple.pkg.Essentials.
Mais par ailleurs, une commande :
Bloc de code:
sudo pkgutil --files com.apple.pkg.Essentials
retourne l'affichage de tous les fichiers installés à partir du paquet cité > le problème étant qu'il s'agit de tous les rouages logiques du Système > donc la liste retournée est kilométrique.
=> il faudrait une patience de bénédictin pour repérer à quel niveau exact d'installation de fichiers il y a eu ainsi une instruction d'
ACE "
remy allow ---" sur le répertoire
Applications > et ce qui a bien pu la générer, étant donné qu'elle ne pouvait précéder en toutes lettres l'atterrissage du package dans le volume du Mac.
=> ce qui me semble bizarre, est le
quadruplet d'
ACE - car c'est seulement dans une suite
Microsoft Office pour Mac qu'on trouve
4 logiciels spécifiques à installer - donc peut-être
4 pkg en provenance de
Microsoft à destination du répertoire des
Applications > on pourrait imaginer alors que ce quadruple
pkg soit la source de la quadruple instruction d'
ACE "
remy allow ---" sur
Applications - le problème étant que ce serait alors un logiciel tiers le responsable, et pas une install-Système Apple > comment alors expliquer qu'une commande
sudo /usr/libexec/repair_packages --repair --standard-pkg / qui ne concerne que les composants Apple rétablisse alors la
quadruple ACE (si c'est bien ce qui arrive chez toi) ?
j'ai ajouté l'option o qui masque le groupe au profit de l'user + l'option g qui masque l'user au profit du groupe > ce qui fait que les 2 sont masqués pour allègement de l'affichage ; et j'ai enlevé l'option d qui traite un dossier comme un fichier plein > ce qui permet l'exploration récursive du contenu de Applications - le reste : inchangé)
r e m y
