maena.
Je t'ai proposé des pistes pour te sortir de ton plantage d'affichage graphique dans le fil spécifique que tu as ouvert => ☞
Bureau totalement vide☜.
----------------------
Pour respecter la cohérence conceptuelle de ce fil-ci consacré à la « question » suivante :
Je voudrais savoir que veux dire le message suivant après une analyse des permissions par l'utilitaire de disque. "ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé." Est dangereux pourquoi ne peux t'on pas le réparer ?
je me permets ici d'entrer dans un certain « détail » (au risque de me montrer inutilement abstrus) rien que pour l'amour
formel de l'art...
=> il convient de savoir qu'un fichier
SUID désigne un fichier de type
exécutable (comme le sont les
binaires UNIX dans
OS X, mais aussi les
fichiers exécutables recelés dans le
bundle des applications) concernant lequel la
permission d'exécuter (marquée par le symbole
x comme
execute en valeur
symbolique) propre à l'
user - ou propriétaire du fichier (lequel dans le cas d'un
exécutable UNIX est toujours
root = le
Super-Administrateur Système), est remplacée par le «
Set_User_ID_bit » symbolisé par un
s à la place du
x.
Le «
Set_User_ID_bit » (
bit de « transfert d'identité de l'utilisateur ») instaure une
permission d'exécution exceptionnelle du fichier en faveur d'un utilisateur
admin qui n'est pas l'utilisateur
root = cet utilisateur
admin bénéficie d'une dissociation entre les 2 fonctions normalement confondues en un même
user : celle d'«
initiataire » d'un processus (
déclencheur d'une exécution) et celle d'«
opérateur » du processus (
responsable d'une exécution). Lorsque le
SUID_bit est instauré, et qu'un
admin intervient comme «
initiataire » (déclencheur de l'exécution du fichier), il n'est pas identifié pas pour autant à l'«
opérateur » du processus, mais par un
transfert d'identité permis par le
SUID_bit, c'est le
Super-User root qui est identifié comme l'«
opérateur » du processus. Bref, familièrement parlant : le
SUID_bit permet à un
admin d'«
opérer » sous l'identité automatique de
root. Quels que soient les
enjeux de l'exécution du
binaire UNIX. Sans avoir besoin de
s'authentifier dans une commande en la préfixant de
sudo et en renseignant un
mot-de-passe admin.
Exemple : si le fichier exécutable
chmod (
change_mode) possède les
permissions standard :
-rwxr-xr-x root wheel, alors un
admin ne peut l'exécuter sur un dossier protégé comme
/private (en permissions
drwxr-xr-x root wheel où seul
root a la permission d'écriture
x) que via une
authentification afin de s'accorder récursivement, supposons, une
permission d'écriture dans les
ACL du dossier et de ses dépendances ainsi :
Bloc de code:
sudo chmod -R +a "admin allow write" /private
+
password
Si le fichier exécutable
chmod porte le
SUID_bit :
-rwsr-xr-x root wheel, alors l'
admin peut se contenter de la commande :
Bloc de code:
chmod -R +a "admin allow write" /private
immédiatement exécutoire, car son «
opérateur » (par le
transfert d'identité du
SUID_bit) est
root quand bien même l'«
initiataire » est-il l'
admin.
En résumé : le
SUID_bit est un passe-droit puissant sur des
exécutables dans
OS X octroyable à un
admin, que ce soit par un acte délibéré de cet
admin (par exemple, par la commande réflexive :
Bloc de code:
sudo chmod 4755 /bin/chmod
+
password, j'instaure un
SUID_bit sur l'exécutable
chmod qui va désormais me permettre d'en «
initier » sans
sudo l'exécution car son «
opérateur » sera toujours identifié à
root) ; soit à l'instigation d'une application requérant pour un de ses exécutables un
SUID_bit permettant désormais à l'utilisateur
admin de le faire opérer directement en
root sans requête d'authentification.
Bien que cette dernière procédure puisse ouvrir théoriquement parlant la porte à des excès, et qu'elle intervienne régulièrement en pratique pour ce qui est de l'exécutable
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent à l'initiative de l'application «
ARDAgent.app» (
Apple Remote Desktop) au bénéfice de l'utilisateur
admin susceptible de l'exécuter, cela n'a jamais dans ce cas précis donné lieu à des abus d'usage répertoriés.
Lorsqu'on demande une vérification/réparation des
permissions, tout exécutable porteur du
SUID_bit est infailliblement repéré comme s'écartant de la valeur normale, mais ce privilège se trouve toujours
respecté et jamais
résilié. D'où la déclaraton classique :
"ATTENTION : le fichier SUID « MACHIN » a été modifié et ne sera pas réparé." => ce qui veut dire : le fichier
exécutable MACHIN a été
modifié dans sa
permission d'exécution régulière
x de l'
user root par substitution du
SUID_bit s permettant un
transfert d'identité automatique d'un «
initiataire »
admin à l'«
opérateur »
root dans tous les cas
sans authentificaton requise => ce privilège extraordinaire ne sera pas
résilié (= "
réparé") mais
respecté.
