54 votes

Pourquoi est-ce que je reçois une erreur de type "propriété douteuse du fichier" lorsque l'agent de lancement exécute mon fichier .plist ?

J'ai un agent de lancement configuré pour exécuter un fichier .plist par exemple : /Library/LaunchAgent/foo.plist . A l'intérieur de ce .plist, il est configuré pour fonctionner pendant LoginWindow y Aqua .

Lorsque j'essaie de lancer mon ordinateur et d'accéder à l'écran de connexion, cette plist devrait s'exécuter mais donne l'erreur suivante (dans la console) :

launchctl : Propriété douteuse sur le fichier (saut) : /Bibliothèque/LaunchAgents/foo.plist

Lorsque j'essaie de me connecter avec un compte non administrateur, le message d'erreur est exactement le même. Lorsque j'essaie de me connecter avec un compte administrateur, cela fonctionne bien.

Je vais être honnête, je ne connais pas grand chose aux privilèges et permissions de Mac OS X.

Pour créer le fichier, je l'ai ouvert dans emacs avec sudo sur le compte administrateur (par exemple en utilisant l'option su puisque l'autre compte n'a pas les privilèges sudo) et l'a ensuite enregistré.

Quel compte dois-je utiliser pour créer le fichier afin qu'il fonctionne pour tous les utilisateurs ?
Dois-je utiliser la commande sudo ?
Dois-je modifier les droits d'accès aux fichiers (par exemple, utiliser la fonction chmod ) ?
Existe-t-il un moyen simple de prendre un fichier existant et de changer sa propriété au lieu de devoir recréer le fichier ?
Quelqu'un pourrait-il expliquer pourquoi cette erreur se produit ?

0 votes

Que donne ls -l pour /Library/LaunchAgent/foo.plist ?

1 votes

@Mark : cela donne ce qui suit : -rw-r--r--@ 1 admin staff 653 Oct 17 14:31 /Library/LaunchAgents/foo.plist

0 votes

Il est également possible de forcer le chargement ( -F ).

51voto

steve_c Points 3887

Si un plist appartient à Root et est accessible en écriture par un utilisateur autre que Root, il y a un problème de sécurité.

Vous pouvez changer le propriétaire en Root avec sudo chown root <filename> et changez les permissions avec sudo chmod 644 <filename> (4 pour l'accès en lecture, 2 pour l'accès en écriture, 1 pour l'accès en exécution, additionnés. Le premier chiffre est pour le propriétaire, le deuxième pour le groupe, le troisième pour tout le monde).

0 votes

Ça marche. Je ne comprends pas pourquoi j'ai dû changer le propriétaire en Root. Root est-il l'utilisateur utilisé pour les LaunchAgents ?

1 votes

Oui, je le pense.

1 votes

Je sais que c'est un ancien message, mais c'est une excellente réponse ! J'ai changé les permissions sur /system/library/launchdaemons/com.apple.mdnsresponder pour essayer un correctif recommandé par Apple, mais j'obtenais l'erreur mentionnée ci-dessus lorsque j'essayais de le charger ensuite. Changer le propriétaire et les permissions comme décrit ci-dessus était le seul moyen de récupérer ma connexion Internet. Merci !

14voto

Nip Points 362

De la launchctl(1) page d'accueil La description que fait l'auteur de la load sous-commande :

Notez que les fichiers de configuration par utilisateur (LaunchAgents) doivent appartenir à l'utilisateur qui les charge. Tous les démons de l'ensemble du système (LaunchDaemons) doivent appartenir à Root. Les fichiers de configuration ne doivent pas pouvoir être écrits par un groupe ou par le monde entier. Ces restrictions sont en place Ces restrictions sont en place pour des raisons de sécurité, car permettre l'écriture d'un fichier de configuration launchd permet de de spécifier quel exécutable sera lancé.

launchctl a plusieurs messages "Dubious ". Le site lancé sur le marché pour 10.6.7 (par exemple) contient trois messages de ce type dans sa version launchctl.c (voir la fonction path_goodness_check ).

  1. Dubious permissions on file (skipping): <pathname>
  2. Dubious ownership on file (skipping): <pathname>
  3. Dubious path. Not a regular file or directory (skipping): <pathname>

Pour éviter ces messages, le chemin d'accès doit être (#3) un fichier ou un répertoire normal. 1 (ou un lien symbolique vers celui-ci) qui (#1) appartient à Root ou à l'utilisateur qui l'invoque et (#2) n'est pas accessible en écriture par un "groupe" ou un "autre" (c.-à-d. chmod go-w ).

1 Pas de tuyaux nommés, de nœuds de périphériques spéciaux bloc/caractère, de sockets de domaine local, etc.


Votre fichier appartient probablement à l'utilisateur admin puisque vous dites que vous n'obtenez pas le message lorsque vous vous connectez en tant que cet utilisateur (le nom du chemin appartient à l'utilisateur qui l'invoque dans ce cas).
Pour que le nom de chemin fonctionne pour les autres utilisateurs, il doit appartenir à Root.

Pour cela, faites :

sudo chown root /Library/LaunchAgent/foo.plist

1voto

n8gray Points 2923

Merci pour la réponse (changer le propriétaire en Root) -- c'est tout ce dont j'avais besoin.

Pour que ce soit un peu plus qu'un post "moi aussi"... Je suis arrivé ici par un chemin alambiqué : Je recevais des erreurs "This API can only be used by a process running within an Aqua session" pour un launchdaemon. La recherche d'une réponse à ce problème m'a conduit à Technote d'Apple sur les démons et les agents qui expliquait comment résoudre l'erreur "Aqua session", mais qui me laissait avec des problèmes de "propriété douteuse". C'est ainsi que je suis arrivé ici, où mon dernier problème a été résolu.

Peut-être que le fait d'ajouter tout cela à cette discussion amènera un moteur de recherche à lier cette page à l'un des problèmes précurseurs, faisant ainsi gagner du temps à un futur aventurier.

0 votes

Remarque : il s'agit d'un commentaire plutôt que d'une réponse.

1 votes

J'aurais bien commenté, mais mes points de réputation n'étaient pas assez élevés. (Ne semble-t-il pas paradoxal que l'on puisse "répondre" avec une faible réputation mais pas commenter) ?

-2voto

radha Points 9

Pour le fichier dans ~/Library/LaunchAgent appartenant à l'utilisateur et non à Root ne sudo, si vous le faites vous devrez changer la propriété puisque vous le chargez depuis l'utilisateur Root

-3voto

Maximo Pech Points 1

C'est ce qui arrive quand les gens ne savent pas comment sudo fonctionne. Pour désactiver les services qui sont sur les fichiers appartenant à votre utilisateur, il suffit d'appeler launchtl sans sudo .

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X