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

J'essaie de comprendre comment lancer une application GUI en tant qu'un autre utilisateur connecté de manière interactive, dans la session graphique de cet utilisateur.

Par exemple, disons que j'ai deux utilisateurs, foo et bar. Les deux sont connectés, mais l'utilisateur interactif actuel est foo. Je voudrais lancer Calculator.app en tant que "barre" de l'utilisateur, de sorte que lorsque je passe rapidement de l'utilisateur à la barre, je trouve que la fenêtre de la calculatrice est ouverte dans la session de la barre.

Voici ce que j'ai essayé qui ne fonctionne pas:

sudo -u bar /Applications/Calculator.app/Contents/MacOS/Calculator

Cela lance Calculator.app sous forme de barre, mais la fenêtre s'ouvre dans la session graphique de foo.

sudo -u bar osascript -e "tell application \"Calculator\" to activate"

Même effet.

sudo -u bar open "/Applications/Calculator.app"

Lance la calculatrice comme foo, pas bar.

launchctl asuser [uid of bar] [any of the above commands]

Même effet.

Existe-t-il un moyen d'y parvenir? Je suis prêt à envisager toutes sortes de solutions possibles, y compris les scripts bash, AppleScript, l'écriture d'un programme Core Foundation ou Cocoa, etc. Dans ma situation, n'importe quel programme ou script peut s'exécuter comme n'importe quel utilisateur, y compris root.

Remarque: je suis conscient qu'il est possible d'utiliser des événements Apple distants, mais je ne peux pas l'utiliser car dans la situation où j'essaie de le faire, je n'ai aucune garantie que les "événements Apple distants" seront activés dans les préférences de partage.

Toute aide serait grandement appréciée!

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é, il est difficile de franchir le fossé de session utilisateur.

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.

Launchd's Bsexec

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

 bslist [PID | ..] [-j]
          This prints out Mach bootstrap services and their respective states. While the namespace
          appears flat, it is in fact hierarchical, thus allowing for certain services to be only avail-
          able to a subset of processes. The three states a service can be in are active ("A"), inactive
          ("I") and on-demand ("D").

          If [PID] is specified, print the Mach bootstrap services available to that PID. If [..] is
          specified, print the Mach bootstrap services available in the parent of the current bootstrap.
          Note that in Mac OS X v10.6, the per-user Mach bootstrap namespace is flat, so you will only
          see a different set of services in a per-user bootstrap if you are in an explicitly-created
          bootstrap subset.

          If [-j] is specified, each service name will be followed by the name of the job which regis-
          tered it.

 bsexec PID command [args]
          This executes the given command in the same Mach bootstrap namespace hierachy as the given
          PID.

 bstree [-j]
          This prints a hierarchical view of the entire Mach bootstrap tree. If [-j] is specified, each
          service name will be followed by the name of the job which registered it.  Requires root priv-
          ileges.

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

Cause des problèmes

Les problèmes proviennent du fait que l'application est connectée au mauvais WindowServerprocessus. Chaque session utilisateur a un WindowServer distinct; 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 sur les démons et les agents d'Apple.

Expérience

Je le sais 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. Bien que notre démon ait l'autorité root, nous avions toujours besoin d'un processus par utilisateur pour fonctionner de manière fiable dans les sessions utilisateur.

Aucune des réponses de bsexec ci-dessus ne fonctionne sur El Capitan (10.11), en raison de la protection de l'intégration du système (SIP) fermant 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 les OS les plus récents):

sudo launchctl asuser 501 open /Applications/Calculator.app

Notez que 501 est l'ID utilisateur de mon autre utilisateur.

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

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

l'homme dit

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

Ainsi, en tant que paramètre PID, vous pouvez utiliser le pid du processus de connexion approprié . L'UID est l'ID utilisateur de l'utilisateur propriétaire de cette fenêtre de connexion et le GID est son groupe principal.

Cela fonctionne très bien pour n'importe quelle commande et bien sûr pour les jobs launchd (par exemple les lanceurs) également 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 autorisations osascript -e "tell application \"Finder\" to open (\"${app}\" as POSIX file as alias)". De cette façon, il sera lancé via n'importe quel contexte GUI lancé Finder.

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 l'essayez via Terminal.app, il ouvre TextEdit dans l'interface graphique de l'utilisateur actuel.

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

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

et le désactiver à nouveau par la suite si nécessaire?

Sinon, je suis perplexe.

Testé le 10.9.

Facile

sudo su name_of_user

puis exécutez les commandes normalement.