Salut
rachtaia.
Pascal t'a répondu sur le point qui te tracassait : lorsqu'on demande la réparation des
permissions dans l'«
Utilitaire de Disque», des annonces ponctuelles du type :
Bloc de code:
ATTENTION : le fichier [COLOR="Red"]SUID[/COLOR] « xxxx » a été modifié et ne sera pas réparé
ne notifient pas une
erreur de l'ordre des
permissions sur un fichier que l'utilitaire serait incapable de corriger ; mais notifient un
privilège de l'ordre des
permissions sur un fichier que l'utilitaire n'a pas à modifier.
♤
Ce
privilège qui est le
SUID (Set User ID - que je vais désormais désigner du nom de la fonction qui l'instaure : le
setuid) peut être rapproché de ces autres privilèges sur des fichiers que sont les
ACL (Access Control Lists : Listes de Contrôle d'Accès), lesquelles
surajoutent un
propriétaire en second au
propriétaire en premier d'un fichier. Elles instaurent donc une
co-propriété. Ce peut être fait pour des fichiers 'personnels', intialement la propriété de M. X, qui, par le truchement d'une
ACL, vont tomber dans la co-propriété de Mme Y --> les 2 co-propriétaires vont pouvoir se partager le privilège, par exemple, de
lire & écrire ce fichier. Idem pour des dossiers personnels. Ce peut être pareillement le cas pour des fichiers qui ne sont plus personnels, mais de l'ordre du fonctionnement du Système, par exemple des fichiers de paramétrage dont régulièrement le propriétaire est le seul
Super_User : root. Un utilisateur-admin peut (à ses risques et périls) imposer une
ACL sur de tels fichiers, en s'instaurant
co-propriétaire du fichier, ce qui lui permet, à l'égal de
root, un
accès propriétaire (
lecture & écriture) au fichier.
Lorsqu'il y a de telles
ACL de
co-propriété sur un fichier, l'«
Utilitaire de Disque», à la vérification/réparation des
permissions, identifie ces
cas d'exceptions sous la notification :
Bloc de code:
ACL trouvée mais non-attendue sur fichier xxxx
et régulièrement ne répare pas cet état de choses, qui n'est pas une
erreur en soi (sauf de la part d'un utilisateur qui fait n'importe quoi), mais un
privilège établi qui doit être respecté.
♧
Ce long préambule permet d'introduire en mode '
analogie' la question du
setuid qui est un privilège
ésotérique dans le fonctionnement d'
OSX. Pour le dire hardiment, le
setuid est l'analogue d'une
ACL lorsque les fichiers qui le supportent ne sont pas des fichiers '
informatifs', mais des fichiers
exécutables - dits
binaires, càd. des
programmes.
Lesdits programmes, pour supporter le
setuid, doivent régulièrement dépendre pour leur fonctionnement du
Super-User : root en tant que
propriétaire --> c'est dire que le lancement de ces programmes a des enjeux-Système
a priori, càd. impacte le fonctionnement même de l'OS dans son architecture (à la différence du programme d'une simple «
application» qui fonctionne sur la base des opérations du Système). Il peut s'agir notamment des
binaires_Unix à effet d'altération du Système qui sont invocables en ligne de commande dans le «
Terminal», par exemple les
binaires : chown (changer les
propriétaires),
chmod (changer les
permissions) ou encore
chflags (changer les
attributs). Mais il peut s'agir aussi des binaires d'applications natives d'Apple chargées de la gestion de fonctionnalités du Système (comme toutes celles recelées dans le répertoire
CoreSystème de la Bibliothèque-Système).
Ces
binaires à 'effet-Système' dépendent régulièrement du
Super-User : root, qui est leur seul
réel propriétaire et par suite leur seul agent
effectuateur possible. Le
setuid signifie :
set user ID = opérer l'identification de l'utilisateur au propriétaire
root sur un
binaire. Il ne s'agit pas exactement de sur-ajouter une
co-propriété (comme pour une
ACL), mais d'opérer une
assimilation a priori d'un utilisateur-admin au propriétaire
root sur un
binaire. Ce qui signifie que l'admin qui bénéficie du
setuid a la capacité de lancer le programme comme s'il était
root lui-même, ledit programme s'exécutant à partir de là
effectivement en droits
root. Il s'agit donc ici du privilège de
se faire-passer pour root pour la mise en route d'un programme.
♡
Ce privilège du
setuid s'instaure par ajout du
setuid_bit sur le
binaire, noté
s. C'est couramment le résultat d'une action délibérée de l'utilisateur-admin qui recourt pour ce faire à l'invocation de
chmod dans le «
Terminal». Ainsi, je peux récursivement invoquer le
binaire : chmod, dont les droits réguliers sont :
Bloc de code:
-rwxr-xr-x 1 root wheel /bin/chmod
sur lui-même par la commande :
Bloc de code:
sudo chmod [COLOR="Red"]4[/COLOR]755 /bin/chmod
ce qui modifie ainsi les droits :
Bloc de code:
-rw[COLOR="Red"]s[/COLOR]r-xr-x root wheel /bin/chmod
--> le
s remplaçant le
w (droit d'
écriture) dans les permissions du propriétaire
root notifiant l'existence d'un
setuid tel que l'admin qui l'a établi se trouve
a priori assimilé à
root en capacité de lancer le programme avec effets-Système en pleins droits
root effectifs dans ses opérations.
♢
Personnellement, j'ai établi volontairement des
setuids sur un certain nombre de
binaires capables d'impacter le Système, ce qui me permet en tant qu'admin, dans le «
Terminal», de les lancer en droits
root en habilitation
a priori, càd. sans avoir à demander au coup par coup l'autorisation ponctuelle de ce privilège par le préfixe
sudo (Substitute User DO --> opérer en qualité d'utilisateur substitut de
root). Il paraît clair, sur ce point, que le
setuid est un privilège d'
assimimilation à root de l'admin sur un
binaire qui induit le même résultat que le préfixe
sudo, avec la différence qu'il s'agit d'un
statut pérenne a priori, et pas d'un
intérim ponctuel.
Lorsque je demande à l'«
Utilitaire de Disque» de réparer les
permissions (j'utilise «
Mavericks 10.9.4»), j'ai une liste substantielle de :
Bloc de code:
ATTENTION : le fichier [COLOR="Red"]SUID[/COLOR] « xxxx » a été modifié et ne sera pas réparé
et je ne peux que me féliciter que les
setuids que j'ai définis ne soient pas 'réparés', car ça m'obligerait à tout recommencer chaque fois!
♙
Le fichier
binaire : ARDAgent est le programme de l'Agent de l'application :
Remote Desktop d'Apple. Je me souviens, lorsque «
Snow Léopard» était mon OS principal, d'avoir eu droit régulièrement à la notification d'un tel fichier
SUID sans que j'aie moi-même opéré délibérément le
setuid sur ce
binaire --> il est possible que le
setuid_bit se trouve établi sur le programme par l'intermédiaire d'une autre application ayant réclamé pour ce faire une authentification unique à l'instauration.
J'ajoute qu'un aspect commode du
setuid consiste dans l'exécution de
scripts_shell avec droits
root a priori : il suffit, en effet, d'instaurer
root en propriétaire de
première instance de l'exécutable, puis en
deuxième instance d'établir le
setuid_bit sur le fichier, assimilant l'admin à
root dans sa capacité à le faire opérer
effectivement.
Revers de la médaille : des instructions dévastatrices peuvent d'exercer de cette façon sans obstacle...
♘