Non !
[MODE_JARGON]
Le message signale (dans le délicieux langage
Volapük de l'informatique) que le fichier localisé at:
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent (fichier
ARDAgent faisant partie de l'application «
ARDAgent.app» contenue dans le répertoire
CoreService de la Bibliothèque du Système) est porteur d'un
SUID_bit (c'est le bit du "
Substitute User ID" = opérer sous l'IDentité de Substitution de l'Utilisateur
root). Il s'agit d'une permission d'exécution spéciale autorisant, concernant un fichier exécutable dont
l'user réglementaire est
root (le Super-Admistrateur Système), un utilisateur autre que l'utilisateur
root réglementaire, de lancer par une commande directe l'exécution du fichier, sans que son identité d'«
initiateur» du processus soit celle de l'«
opérateur» du processus qui reste
root. En gros : c'est comme si une simple cuisinière faisait faire les courses par sa patronne sans que cette dernière ne regimbe...
Personnellement, j'ai volontairement instauré le
SUID_bit sur des tas de binaires (fichiers exécutables
UNIX de l'OS), ce qui fait que, dans le «
Terminal», je n'ai jamais plus à demander d'autorisation spéciale (par l'invocation de
sudo) pour les faire opérer avec les privilèges
root. Car le
SUID_bit m'accorde a priori ce droit, en dissociant mon identité d'
initiateur du processus de celle de l'
opérateur du processus qui reste
root. Je
lance le binaire en tant que
macomaniac, mais il s'exécute en tant que relevant de l'
opérateur root. Je me suis donné ce privilège de me faire passer pour l'
opérateur root à tous les coups pour chaque invocation dudit binaire (exemples de binaires :
chown,
chmod,
chflags etc.).
Dans le cas du binaire :
ARDAgent, c'est un grand classique (dans
OS X) du
SUID_bit dont l'utilisateur
admin n'est pas le créateur volontaire. Je me figure qu'une application (mais je n'ai jamais eu la curiosité de chercher à savoir laquelle) procure ("
à l'insu de son plein gré") à l'utilisateur
admin le
SUID_bit sur ce fichier (par une première et unique authentification pour l'instaurer), afin de faciliter son exécution directe ultérieure sans qu'il soit besoin chaque fois de réclamer une authentification par mot-de-passe (l'équivalent de
sudo). Je n'ai jamais ouï d'écho qu'il y aurait des abus d'usage liés à ce
SUID_bit. Car il est bien évident que le
SUID_bit accorde un privilège assez exorbitant à un utilisateur - privilège dont bénéficient les processus qui se lancent en son nom en exécutant le fichier porteur du
SUID_bit en mode
root sans que l'utilisateur en soit nécessairement averti.
Lorsque une permission de type
SETUID_bit (qui modifie l'
executable_bit de l'utilisateur
root d'un binaire) est instaurée, alors le "
x" de l'
executable_bit est remplacé par le "
s" du "
SETUID_bit", ce qui donne un :
-rwsr-xr-x root wheel pour les permissions du binaire. Lorsqu'on demande, ensuite, à l'«
Utilitaire de Disque» de "
Réparer les permissions", le logiciel détecte l'anomalie dans les permissions du fichier concerné par le
SETUID_bit (
-rwsr-xr-x trouvé, mais
-rwxr-xr-x attendu) mais il ne restaure jamais l'
executable_bit par défaut, mais laisse en place le
SETUID_bit (sinon, après chaque "
Réparation des permissions", il faudrait recréer
a la mano tous les
SETUID_bits des binaires qui en portaient - pour un utilisateur qui en utilise le procédé - ce qui serait une croix). Donc l'«
Utiltaire de Disque» se contente de déclarer : "
Warning : SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified et will not be repaired" (ce qui veut dire : l'
excutable bit x de l'utilisateur
root a été modifié en un
SETUID_bit s sur le fichier machin, mais cette substitution ne sera pas réparée par restauration de l'
executable_bit x pour ramener le privilège exécutable à l'utilisateur seul).
De mémoire, j'ai toujours eu le fichier
ARDAgent porteur du
SETUID_bit depuis mes premiers
OS X (sans que j'y sois pour rien ce coup-ci) et je ne m'en suis jamais formalisé. Je viens de faire le test que je te convie à faire : si tu vas à
/Applications/Utilitaires et que tu lances le «
Terminal» pour copier-coller dans sa fenêtre la commande (simplement infomative) :
Bloc de code:
ls -al /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande), je te parie que tu vas obtenir comme information en réponse :
Bloc de code:
-rwsr-xr-x 1 root wheel ....
concernant les permissions du fichiers, avec un
s en 4è caractère. C'est ce que j'ai aussi dans mon «
Yosemite 10.10.5» actuel. RAS.
[/MODE_JARGON]
