Як запустити програму GUI у графічному сеансі іншого користувача?

Я намагаюся розібратися, як запустити програму GUI як іншого користувача, який увійшов у систему інтерактивно, у графічному сеансі цього користувача.

Наприклад, скажіть, що у мене є два користувачі, foo та bar. Обидва зареєстровані, але поточний інтерактивний користувач foo. Я хотів би запустити Calculator.app як "бар" користувача, щоб, коли я швидко переключився на бар, я виявив, що вікно "Калькулятор" відкрите в сеансі бар.

Ось що я спробував, що не працює:

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

Це запускає Calculator.app як бар, але вікно відкривається в графічному сеансі foo.

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

Такий же ефект.

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

Запускає калькулятор як foo, а не bar.

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

Такий же ефект.

Чи є спосіб досягти цього? Я готовий розважати всіма можливими рішеннями, включаючи баш сценаріїв, AppleScript, написання програми Core Foundation або програми з какао тощо. У моїй ситуації будь-яка програма або сценарій може виконуватись як будь-який користувач, включаючи root.

Примітка. Я знаю, що це можливо за допомогою віддалених подій Apple, але я не можу це використовувати, оскільки в ситуації, яку я намагаюся зробити це, я не маю гарантії, що "Віддалені події Apple" будуть включені в налаштуваннях спільного доступу.

Будь-яка допомога буде дуже вдячна!

Те, що ви хочете досягти, можливо, але важко. Вам потрібно запустити програму протягом відповідного сеансу користувача. З міркувань безпеки перетнути поділ сеансу користувача складно.

Вам потрібен процес, який вже запущений у сеансі іншого користувача, щоб прослухати ваш запит та запустити програму від вашого імені.

bsexec

На щастя, останні версії launchdмають таку можливість; хоча інженери Apple не рекомендували його загального використання. Використовуйте bsexecопцію в launchctl для націлювання на відповідний сеанс користувача:

 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.

Рекомендований підхід полягає в тому, щоб написати пусковий квиток на роботу та перезапустити Mac - або попросити користувача вийти з системи та знову ввійти.

Причина проблем

Проблеми пов'язані з підключенням програми до неправильного WindowServerпроцесу. Кожен сеанс користувача має окремий сервер WindowServer; цей процес обробляє користувальницький інтерфейс. Ваші попередні методи передають право власності на процес потрібному користувачеві, але підключено до власного процесу WindowServer.

Ця проблема згадується в технічній записці компанії Daemons and Agents від Apple.

Досвід

Я знаю це з особистого досвіду. Для Power Manager я писав, що pmuser існує в кожному сеансі користувача. pmuserслухає наш демон і обробляє запуски та команди кожного користувача. Незважаючи на те, що наш демон має повноваження root, нам все ж потрібен процес користувача, щоб надійно працювати в межах сеансів користувача.

Жоден з bsexec не відповідає вищевказаній роботі над El Capitan (10.11) через захист інтеграції системи (SIP), що закриває порти. "startctl asuser" працює, але його потрібно запускати як root. Команда нижче працює на El Capitan (і останні ОС):

sudo launchctl asuser 501 open /Applications/Calculator.app

Зауважте, що 501 є userid для мого іншого користувача.

Оскільки нарешті 10.10 забезпечує правильну реалізацію "startctl bsexec", яку ви можете використовувати:

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

каже людина

Це виконує задану команду в максимально схожому контексті виконання з цільовим PID.

Отже, як параметр PID, ви можете використовувати pid відповідного процесу входу в систему . UID - це ідентифікатор користувача, який має власник цього вікна входу, а GID - це його основна група.

Це добре працює для будь-якої команди та, звичайно, для запущених завдань (fe startchagents), нарешті, як:

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

Ви можете використовувати Finder як хост для правильних дозволів osascript -e "tell application \"Finder\" to open (\"${app}\" as POSIX file as alias)". Таким чином він запускатиметься через будь-який контекст GUI, який запускається Finder.

Це працює через 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

але якщо спробувати його через Terminal.app, він відкриє TextEdit в GUI поточного користувача.

Якщо ви не впевнені, що sshце ввімкнено, можливо, ви можете тимчасово його ввімкнути

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

і відключити його знову, якщо потрібно?

Інакше я застряг.

Випробувано 10.9.

Простий

sudo su name_of_user

потім виконувати команди нормально.