En ce qui concerne ta réparation des autorisations --> il n'y a aucun problème en dépit des apparences. Car :
- les
.nib sur lesquels est attendu un
drwxr-xr-x (
d =
directory : dossier > suivi de permissions standard en lecture / écriture / exécution) et trouvé un
-rwxr-xr-x (
- = fichier > suivi des mêmes permissions en lecture / écriture / exécution) --> il s'agit de ressources d'affichage graphique recelées dans le paquetage d'applications, dont la nature traditionnelle était d'être des
dossiers (
d) > et qui sont devenues récemment des
fichiers compilés (
-).
Il suffit que dans ton OS qu'on supposera un peu ancien > dans lequel les versions originelles de «
Safari» et d'«
iTunes» comportaient des "
nib =
dossiers" > tu aies injecté des versions de «
Safari» et «
iTunes» nettement plus récentes > dans lequelles les
nib =
fichiers-compilés => pour que le processus de vérification de l'«
Utilitaire de Disque», qui se réfère comme paradigme à des fichiers "catalogue d'installation" (
.bom) de l'OS et de ses applications > trouve une référence à des
nib =
dossiers > alors que les applications actuelles plus récentes recèlent des
nib =
fichiers.
=>
en résumé : simple décalage temporel. Tes «
Safari» et «
iTunes» sont plus avancés que ton OS.
--------------------
- le (fameux) message :
Bloc de code:
ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/
Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.
signifie qu'un fichier exécutable intitulé
ARDAgent d'une application des
CoreServices de l'OS > a bénéficié d'une
permission spéciale après installation de l'OS : le
SETUID_bit (
SET_User_ID_bit : établissement d'une identité
root exécutive). Celle-ci permet (en résumé) à un utilisateur qui n'est pas le
System Administrator (mais toi, par exemple) > de lancer l'exécution du fichier en tant qu'opérateur ayant automatiquement l'identité de root > sans avoir eu besoin d'une élévation préalable de privilièges.
Le fichier
ARDAgent se trouve
toujours affecté de cette élévation de permission (le
SETUID_bit) en cours d'utilisation de l'OS (non à son installation première) : il n'y a donc là aucune anomalie qui serait spécifique à ton OS.
L'«
Utilitaire de Disque» là encore, en consultant le "catalogue d'installation" (fichiers
.bom) de l'OS comme paradigme > lit des permissions standards attendues sur le fichier > et ne peut que constater le décalage du
SETUID_bit trouvé. Mais, dans ce cas
spécifique, il ne tente
jamais aucune manœuvre de reconversion - un
SETUID_bit étant toujours le produit d'une opération délibérée sur un fichier.
=>
en résumé : RAS. Un grand classique.
--------------------
» est plus moderne que ton OS. Cet écart pourrait-il aller jusqu'à une instabilité ?
