Comment lancer une application GUI dans la session graphique d'un autre utilisateur ?

Aucune des réponses bsexec ci-dessus ne fonctionne sur El Capitan (10.11), en raison de la Protection de l'Intégrité du Système (SIP) qui ferme les ports. "launchctl asuser" fonctionne, mais nécessite d'être exécuté en tant que root. La commande ci-dessous fonctionne sur El Capitan (et la plupart des systèmes d'exploitation récents) :

sudo launchctl asuser 501 open /Applications/Calculator.app

Notez que 501 est l'identifiant utilisateur pour mon autre utilisateur.

Ce que vous voulez réaliser est possible mais difficile. Vous devez lancer l'application dans la session utilisateur appropriée. Pour des raisons de sécurité, franchir la séparation des sessions utilisateur est difficile.

Vous avez besoin d'un processus déjà en cours d'exécution dans la session de l'autre utilisateur pour écouter votre demande et lancer l'application en votre nom.

bsexec de launchd

Heureusement, les versions récentes de launchd ont cette capacité; bien que les ingénieurs d'Apple n'aient pas recommandé son utilisation générale. Utilisez l'option bsexec dans launchctl pour cibler la session utilisateur appropriée :

 bslist [PID | ..] [-j]
          Cela affiche les services de démarrage de Mach et leurs états respectifs. Bien que l'espace
          de noms semble plat, il est en fait hiérarchique, permettant ainsi à certains services d'être uniquement disponibles pour un sous-ensemble de processus. Les trois états dans lesquels un service peut se trouver sont actif ("A"), inactif
          ("I") et à la demande ("D").

          Si [PID] est spécifié, afficher les services de démarrage de Mach disponibles pour ce PID. Si [..] est
          spécifié, afficher les services de démarrage de Mach disponibles dans le parent du démarrage actuel.
          Remarquez que dans Mac OS X v10.6, l'espace de noms de démarrage Mach par utilisateur est plat, donc vous ne verrez que
          un ensemble de services différents dans un démarrage par utilisateur si vous êtes dans un sous-ensemble de démarrage créé explicitement.

          Si [-j] est spécifié, chaque nom de service sera suivi du nom de la tâche qui l'a enregistré.

 bsexec PID commande [args]
          Cela exécute la commande donnée dans la même hiérarchie de l'espace de noms de démarrage de Mach que le
          PID donné.

 bstree [-j]
          Cela affiche une vue hiérarchique de l'ensemble de l'arbre de démarrage de Mach. Si [-j] est spécifié, chaque
          nom de service sera suivi du nom de la tâche qui l'a enregistré.  Nécessite des privilèges root.

L'approche recommandée est d'écrire un ticket de tâche launchd et de redémarrer le Mac - ou de demander à l'utilisateur de se déconnecter et de se reconnecter.

Origine des Problèmes

Les problèmes découlent du fait que l'application est connectée au mauvais processus WindowServer. Chaque session utilisateur a un WindowServer séparé; ce processus gère l'interface utilisateur. Vos méthodes antérieures placent la propriété du processus avec le bon utilisateur mais connecté à votre propre processus WindowServer.

Ce problème est mentionné dans la note technique Adémon et Agents d'Apple.

Expérience

Je sais cela par expérience personnelle. Pour Power Manager, j'ai écrit pmuser pour exister dans chaque session utilisateur. pmuser écoute notre démon et gère les lancements et commandes par utilisateur. Malgré notre démon ayant une autorité root, nous avions encore besoin d'un processus par utilisateur pour fonctionner de manière fiable dans les sessions utilisateur.

Comme enfin 10.10 fournit une implémentation correcte de "launchctl bsexec", vous pouvez utiliser :

sudo /bin/launchctl bsexec PID chroot -u UID -g GID / open /Applications/TextWrangler.app

l'homme dit

Ceci exécute la commande donnée dans un contexte d'exécution aussi similaire que possible au PID cible.

Donc en tant que paramètre de PID, vous pouvez utiliser le PID du processus loginwindow approprié. L'UID est l'identifiant d'utilisateur de l'utilisateur qui possède ce loginwindow et le GID est son groupe primaire.

Cela fonctionne bien pour n'importe quelle commande et bien sûr aussi pour les jobs launchd (par exemple, les launchagents) enfin comme :

/bin/launchctl bsexec 104 chroot -u 501 -g 20 / /bin/launchctl load -S Aqua /Library/LaunchAgents/com.youragent.plist 2>&1

Vous pouvez utiliser le Finder comme hôte pour les bonnes permissions osascript -e "tell application \"Finder\" to open (\"${app}\" as POSIX file as alias)". De cette façon, il se lancera via le contexte GUI depuis lequel le Finder a été lancé.

Cela fonctionne via ssh :

#!/bin/bash

PID=$(ps auxwww | egrep "^bar" |\
fgrep /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow |\
awk '{print $2}')

sudo launchctl bsexec "$PID" open -a TextEdit

mais si vous essayez via Terminal.app, alors il ouvre TextEdit dans l'interface graphique de l'utilisateur actuel.

Si vous n'êtes pas sûr que ssh soit activé, peut-être pouvez-vous l'activer temporairement

sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist

et le désactiver à nouveau ensuite si nécessaire?

Sinon, je suis coincé.

Testé sur 10.9.