probleme reparation des permission

rachtaia

Membre confirmé
2 Février 2012
78
1
bonjour

J ai un soucis avec les réparations des permissions (peut etre lié a mon probleme de surchauffe)
a chaque fois que je lance la réparation ce sont les même erreur qui revienne dans library/frameworks/javaVM/ et dans labrary/coreservice/

j ai ce message aussi dans l historique de réparation
ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.

je suis sous osx 10.6.8

Merci





Note de la modération: pas trop de rapport avec les portables Mac, je déplace dans le forum adéquat.
 
Dernière édition par un modérateur:
Tu as été aidé, à ton tour d'aider.

Aide les suivants qui auraient un problème similaire.
Comment?
Cliquer "résolu"
( via le menu "outils de la discussion", en haut à droite)
 
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...

♘
 
Dernière édition par un modérateur:
  • J’aime
Réactions: scoliaste
:up: Macomaniac, j'ignorais tout ça, n'empêche je suis bien soulagé de n'avoir plus que 2 lignes de temps en temps en réparation au lieu de dixaines de milliers pendant une période :D