як використовувати xauth для запуску графічного додатку через іншого користувача на Linux


48

Мій звичайний обліковий запис користувача - це, скажімо, user1. Я створив окремий user2 для якоїсь програми x, яку я хотів би запустити під час входу в x як user1, але таким чином, щоб не допустити доступу до читання / запису до даних user1. Я думав, що я можу використовувати xauth та sudo / su для user2 від user1 для запуску цієї програми. Як це зробити? Я не впевнений, як налаштувати xauth.

Відповіді:


32

Щоб використовувати xauth вибірково під час запуску user1:

xauth list|grep `uname -n`

Це друкує записи авторизації hexkey для вас. У вас також можуть бути різні дисплеї, пов’язані з цими хостами.

Як користувач2 встановив ваш дисплей (якщо вважати випадок за умовчанням):

DISPLAY=:0; export DISPLAY

Потім запустіть:

xauth add $DISPLAY . hexkey

Зверніть увагу на крапку після $ DISPLAY та перед шестигранним знаком.

Коли доступ більше не потрібен, як user2 ви можете запустити:

xauth remove $DISPLAY

Проблема 1: user2 не має .Xauthorityфайлу в домашній директорії user2. Проблема 2: Якось і чомусь я не розумію, після цього su, XAUTHORITY тримає файловий шлях до user1's. Але цей файл не читабельний користувачем2.
Отей

Здається, ви забули unset XAUTHORITY під user2
socketpair

є hexkeyв xauth addкоманді так само , як з xauth listабо я повинен створити випадковий новий?
bonanza

bonanza: це один вихід із списку xauth.
Джон Ейкенберрі

1
Ще один спосіб зробити це було б на кшталт ... "екстракт xauth - $ DISPLAY | sudo -iu steam xauth merge -". У цьому випадку у мене є XAUTHORITY, встановлений у .profile, тому "sudo -i" отримує цей набір правильно.
Джон Ейкенберрі

12

Я ставлю свою .zshrcлінію з export XAUTHORITY=~/.Xauthorityі тепер я можу виконати sudo -E xcommand. Після багатьох гуглів для мене це був найпростіший спосіб.


1
Зауважте, що ця процедура зазвичай не вимагає від вас використання sudo -E(а використання -Eвимкнено для більшості встановлень за замовчуванням), оскільки зазвичай sudoersконфігурація за замовчуванням дозволить XAUTHORITYпередати змінну середовища в sudo.
Гасс

@Guss Це не вимагає -E . Його можна встановити як змінну, яку можна передавати, і Red Hat або Debian пропонує це.
Даніель К. Собрал

@ DanielC.Sobral - ось що я сказав :-)
Guss

@Guss О, вибач. Я якось перевернув кожне написане вами речення. :-)
Даніель К. Собрал

Ще не працював для мене на Mac OS X з zsh
Шрідхар Сарнобат

9

Якщо припустити debian або ubuntu (має бути схожим на Red Hat / SUSE).

sudo apt-get install sux
sux user -c 'command'

+1 хороша відповідь, немає сенсу винаходити колесо. До речі, sux здебільшого робить те, що пропонує моя відповідь вище. Це набагато потужніше і простіше у використанні.
sleske

Ви можете зауважити, що "sux" справді теж є простим сценарієм оболонки ..
Martin Mächler

5
suxце НЕ супроводжується (і видаляються з репозиторіїв Debian / Ubuntu в): packages.qa.debian.org/s/sux/news/20140101T172633Z.html
Rob W

9

По-перше: не використовуйте xhost +, це досить небезпечно (ковдра дозволяє / заборонити).

Швидше скористайтеся механізмом X-Cookie:

su user2
cp /home/user1/.Xauthority /home/user2/.Xauthority 
export DISPLAY=:0

Якщо ви suxвстановили, використовуйте це (див. Відповідь ehempel).

В обох випадках user2 використовуватиме секретний файл cookie в .Xauthority для авторизації на сервері X, і ніхто більше не матиме доступу до нього.

Примітки:

  • Залежно від ваших дозволів на файл, можливо, доведеться скопіювати .Xauthority іншим способом.
  • Замість копіювання .Xauthorityви також можете xauthскопіювати та скопіювати ключ авторизації (див. Відповідь Рандалла). Якщо у .Xauthorityфайлі є кілька клавіш, це більш вибірково; інакше це питання смаку.

так, у мене є кореневий доступ до цієї машини
Філ

Це просто вручну скопіювати файли cookie xauth через кореневий доступ. Це не відрізняється від використання xauth, як пояснює Рендалл у (поточній) верхній відповіді, за винятком того, що він копіює кожен файл cookie, який відображатиметься у списку xauth. Отже, це менш безпечно, ніж відповідь на верхній xauth, який додав би лише печиво, яке ви вибрали.
Джон Ейкенберрі

@JohnEikenberry: Правда, дякую, що вказали на це. Я оновив свою відповідь.
sleske

7

Це вирішить проблему для всіх користувачів:

cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF

Це в основному те, що я зробив, і це чудово працює, дякую!
Гасс

4

Як корінь:

xhost local:yourusername

Де ваше ім’я користувача - ваше ім’я користувача :)

Потім зробіть так, як ваш користувач xclockповинен працювати, якщо він встановлений


2

Це просто хаки:

  • xauth + (незахищено)
  • ssh -X user2 @ localhost (некрасиво)

Sleske вище має, я думаю, правильне рішення.


ssh -X- це дуже просте і елегантне рішення, не залежне від будь-яких застарілих / незбережених gtk / kde-матеріалів (для яких потрібно встановити більше бінарних файлів з бітом SUID ...).
Стефан

2

Я знайшов щось, що для мене чудово працює в KDE

kdesu -u username /path/to/program

На частині debian kde-cli-tools, а не в, $PATHале в /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu(очевидно, залежно від архітектури).
Стефан

0

Це зроблено у suse / opensuse: http://www.novell.com/support/kb/doc.php?id=7003743

Просто змінивши /etc/pam.d/su, додавши параметр (напівжирний):

сеанс необов'язково pam_xauth.so systemuser = 1

Тоді ви можете перемикатися з su без -:

su user2

і запустити додаток графічно.


-1

Для GNOME (і справді без будь-якого середовища на робочому столі, я використовую його лише з icewm) gksu:

gksu -u username program

"gksu застаріли роками": bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236
Стефан

@ Стефан зауважимо, що ця помилка Debian - це припущення, що підвищення привілеїв для всієї програми є поганою ідеєю, і що замість цього програма повинна бути модифікована для того, щоб просто виконувати мінімальні помічники з підвищеними привілеями (використовуючи PolicyKit). Це питання (і моя відповідь) стосується зменшення привілеїв, що зовсім інша річ і насправді гарна ідея (наприклад, для випадкового перегляду у мене є ярлик, який виконує firefox під якимсь менш привілейованим обліковим записом, ніж мій за замовчуванням, тому будь-який експлуатувати там можна не торкаюся моїх даних - і gksu (8) для цього цілком чудово)
Matija Nalis

Все це добре, але використовувати застарілий і непідтримуваний бінарний SUID - це просто неправильно. Ця відповідь могла бути корисною в минулому, але вже не.
Стефан
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.