¿Cómo lanzar una aplicación GUI en la sesión gráfica de otro usuario?

13

Estoy intentando descubrir cómo lanzar una aplicación GUI como otro usuario que ha iniciado sesión de forma interactiva, en la sesión gráfica de ese usuario.

Por ejemplo, digamos que tengo dos usuarios, foo y bar. Ambos están conectados, pero el usuario interactivo actual es foo. Me gustaría iniciar Calculator.app como "barra" de usuario, de modo que cuando cambio rápidamente de barra a barra, encuentro que la ventana de la Calculadora está abierta en la sesión de la barra.

Esto es lo que he intentado que no funciona:

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

Esto inicia Calculator.app como barra, pero la ventana se abre en la sesión gráfica de foo.

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

Mismo efecto.

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

Inicia la Calculadora como foo, no barra.

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

Mismo efecto.

¿Hay alguna manera de lograr esto? Estoy dispuesto a entretener a todo tipo de soluciones posibles, incluyendo bash scripting, AppleScript, escribir un programa de Core Foundation o Cocoa, y así sucesivamente. En mi situación, cualquier programa o secuencia de comandos podría ejecutarse como cualquier usuario, incluida la raíz.

Nota: Soy consciente de que es posible usar Apple Events remotos, pero no puedo usar eso ya que en la situación que estoy tratando de hacer esto no tengo ninguna garantía de que "Remote Apple Events" esté habilitado en Compartir preferencias.

Cualquier ayuda sería muy apreciada!

    
pregunta GuyGizmo 03.09.2013 - 22:55

5 respuestas

7

Lo que quieres lograr es posible pero difícil. Debe iniciar la aplicación dentro de la sesión de usuario apropiada. Por razones de seguridad, cruzar la división de sesión del usuario es difícil.

Necesita un proceso que ya se esté ejecutando en la sesión del otro usuario para escuchar su solicitud e iniciar la aplicación en su nombre.

bsexec de launchd

Afortunadamente, las versiones recientes de launchd tienen esta habilidad; Aunque los ingenieros de Apple no han recomendado su uso general. Use la opción bsexec en launchctl para apuntar la sesión de usuario apropiada:

 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.

El enfoque recomendado es escribir un ticket de trabajo de launchd y reiniciar la Mac, o pedirle al usuario que cierre la sesión y vuelva a iniciarla.

Causa de los problemas

Los problemas se derivan de la aplicación conectada al proceso WindowServer incorrecto. Cada sesión de usuario tiene un WindowServer separado; este proceso maneja la interfaz de usuario. Sus métodos anteriores colocan la propiedad del proceso con el usuario correcto pero conectado a su propio proceso de WindowServer.

Este problema se menciona en la Daemons and Agents nota de Apple.

Experiencia

Lo sé por experiencia personal. Para Power Manager, escribí pmuser para existir dentro de cada usuario sesión. pmuser escucha nuestro demonio y maneja los comandos y los lanzamientos por usuario. A pesar de que nuestro daemon tiene autoridad de root, todavía necesitábamos un proceso por usuario para trabajar de manera confiable dentro de las sesiones de usuario.

    
respondido por el Graham Miln 18.09.2013 - 09:47
4

Ninguna de las respuestas de bsexec anteriores funciona en El Capitán (10.11), debido a que la Protección de integración del sistema (SIP) cierra los puertos. "launchctl asuser" funciona, pero debe ejecutarse como root. El siguiente comando funciona en El Capitán (y en los sistemas operativos más recientes):

sudo launchctl asuser 501 open /Applications/Calculator.app

Tenga en cuenta que 501 es el ID de usuario de mi otro usuario.

    
respondido por el Boris Vidolov 24.03.2016 - 00:00
1

Como finalmente 10.10 proporciona una implementación correcta de "launchctl bsexec", puede utilizar:

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

el hombre dice

  

Esto ejecuta el comando dado en un contexto de ejecución lo más similar posible al PID de destino.

Por lo tanto, como parámetro PID, puede utilizar el pid del proceso loginwindow apropiado. El UID es el ID de usuario que posee el usuario en esa ventana de inicio de sesión y el GID es su grupo principal.

Esto funciona bien para cualquier comando y, por supuesto, también para los trabajos launchd (por ejemplo, launchagents) como:

/bin/launchctl bsexec 104 chroot -u 501 -g 20 / /bin/launchctl load -S Aqua /Library/LaunchAgents/com.youragent.plist 2>&1
    
respondido por el Hofi 20.06.2015 - 19:52
0

Esto funciona a través de 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

pero si lo intenta a través de Terminal.app, entonces abre TextEdit en la GUI del usuario actual.

Si no estás seguro de que ssh esté habilitado, quizás puedas habilitarlo temporalmente

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

y deshabilítelo de nuevo si es necesario?

De lo contrario estoy perplejo.

Probado el 10.9.

    
respondido por el TJ Luoma 23.10.2013 - 10:06
-1

Simple

  

sudo su name_of_user

luego ejecuta los comandos normalmente.

    
respondido por el PandB Software 11.02.2017 - 21:05

Lea otras preguntas en las etiquetas