La laborieuse réparation des autorisations de Leopard, Réactions à la news du 05-11-2007

[Lionel]

Ceux qui ont eu besoin de réparer les autorisations de leur ordinateur sous Leopard l'ont constaté. Tout n'est pas aussi simple que sous les précédente versions de Mac OS X.
Pour commencer, lorsqu'on lance une réparation des autorisation, le système lance plusieurs process:
- mds qui consomme 20% des ressources CPU d'un Xeon 3 GHz
- installdb qui va accaparer la totalité de la puissance d'un coeur, près de 97%
- puis ensuite repair_packages qui lui aussi va en faire autant avec 97% des ressources.
Si ces choses se font assez rapidement sur un Mac Intel elle sont déjà bien moins rapides qu'avec les versions précédentes de Mac OS X mais elles virent carrément au calvaire avec une machine moins puissante qui peut se retrouver à mouliner pendant une heure afin de tout vérifier !
Notez qu'un bug assez courant se produit également pour ceux qui ont installé la dernière mise à jour Apple remote Desktop Client. Ils ont droit à l'erreur suivante:

ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.

Aucune possibilité n'est donnée pour la réparer d'une manière ou d'une autre. Il faudra certainement une mise à jour de la mise à jour pour corriger ce petit bug.

Il est plus que probable que cette fonction importante de Leopard sera optimisée dans les prochaines mises à jour. Dans l'état, elle est difficilement utilisable alors qu'elle reste le meilleur moyen de résoudre des comportements étranges du système.

[jujuhtst]

Pourquoi tu casserais moins en sudo qu'en root? Les droits sont identiques, après si tu sais pas ce que tu fais ou tu ne sais pas te relire en root, tu ne sauras pas non plus en sudo.

Je parle de se "logguer" en root. Et le sudo faut l'entrer à chaque commande (il demande le mot de passe uniquement la première fois pdt un certain temps) donc je trouve que le sudo oblige plus de vigilance que de se logguer une fois pour toute en root.

La méthode par clef a des inconvénients... tu n'es pas toujours sur ton poste de travail quand à minuit il faut régler un problème.

Je suis d'accord avec ça

Pour bosser en root via ssh sur des machines qui sont configurées pour refuser une connexion root :
- tu te connectes en user
- tu "su"

Je dirai juste :
"privilege escalation vulnerability"
Un utilisateur distant ne devrait ni pouvoir faire du "su" ni "sudo" ... (enfin il ne devrait parfois même pas pouvoir se logguer pour une sécurité correcte )

Ce message a été modifié par jujuhtst - 8 Nov 2007, 18:40.