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

48

Моя обычная учетная запись пользователя, скажем, user1. Я создал отдельное user2 для некоторого x-приложения, которое я хотел бы запустить при входе в x под именем user1, но таким образом, чтобы он не имел доступа для чтения / записи к данным user1. Я думал, что я мог бы использовать xauth и sudo / su для user2 от user1 для запуска этого приложения. Как мне это сделать? Я не уверен, как настроить xauth.

linux sudo

— Фил
источник

32

Чтобы использовать xauth выборочно, запустите user1 :

xauth list|grep `uname -n`

Это напечатает записи авторизации hexkey для вас. Вы также можете иметь разные дисплеи, связанные с этими хостами.

В качестве user2 установите ваш дисплей (при условии регистр по умолчанию):

DISPLAY=:0; export DISPLAY

Затем запустите:

xauth add $DISPLAY . hexkey

Обратите внимание на точку после $ DISPLAY и перед гекски.

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

xauth remove $DISPLAY

— Randall
источник

Проблема 1: у user2 нет .Xauthorityфайла в домашнем каталоге user2. Проблема 2: Почему-то и по какой-то причине я не понимаю, после того su, как XAUTHORITY содержит путь к файлу user1. Но этот файл не читается пользователем2.

— Отей

Кажется, вы забыли unset XAUTHORITY под user2

— socketpair

это hexkeyв xauth addкоманде то же, что и из xauth listили я должен создать случайный новый?

— Bonanza

bonanza: это единственный выход из списка xauth.

— Джон Эйкенберри

1

Другим способом сделать это было бы что-то вроде ... "xauth extract - $ DISPLAY | sudo -iu steam xauth merge -". В этом случае у меня установлен XAUTHORITY в .profile, так что 'sudo -i' правильно установит это.

— Джон Эйкенберри

12

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

— kfl62
источник

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'

— ehempel
источник

+1 хороший ответ, нет смысла изобретать велосипед. Кстати, sux в основном делает то, что предлагает мой ответ выше. Это более мощный и простой в использовании, конечно.

— Слеське

Вы можете заметить, что 'sux' действительно является простым сценарием оболочки ..

— Мартин Мехлер

5

suxне поддерживается (и удален из репозиториев Debian / Ubuntu): packages.qa.debian.org/s/sux/news/20140101T172633Z.html

— Роб 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файле, это более избирательно; в противном случае это вопрос вкуса.

— sleske
источник

да, у меня есть root-доступ на этой машине

— Фил

Это просто копирование файлов cookie Xauth вручную с помощью root-доступа. Это ничем не отличается от использования xauth, как объясняет Рэндалл в (текущем) верхнем ответе, за исключением того, что копирует каждый файл cookie, который будет отображаться в «списке xauth». Так что это менее безопасно, чем топовый ответ на xauth, который добавил бы только те куки, которые вы выбрали.

— Джон Эйкенберри

@JohnEikenberry: правда, спасибо за указание на это. Я обновил свой ответ.

— слеске

7

Это решит проблему для всех пользователей:

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

— JMS
источник

Это в основном то, что я сделал, и это прекрасно работает, спасибо!

— Гусс

4

Как корень:

xhost local:yourusername

Где yourusername это ваше имя пользователя :)

Затем сделайте su, как ваш пользователь xclockдолжен работать, если он установлен

— ACV
источник

2

Это просто хаки:

xauth + (небезопасный)
ssh -X user2 @ localhost (безобразно)

Слеське выше, я думаю, правильное решение.

— Алекс
источник

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

и запустить приложение графически.

— pojem
источник

-1

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

gksu -u username program

— Матия Налис
источник

«gksu устарела в течение многих лет»: bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

— Стефан,

@Stefan обратите внимание, что эта ошибка Debian состоит в том, что повышение привилегий для всей программы - плохая идея, и что вместо этого программу следует модифицировать, чтобы вместо этого просто выполнять минимальных помощников с повышенными привилегиями (используя PolicyKit). Этот вопрос (и мой ответ) о снижении привилегий, что совсем другое и фактически хорошая идея (например, для случайного просмотра у меня есть ярлык, который запускает firefox под какой-то менее привилегированной учетной записью, чем моя учетная запись по умолчанию, так что любой эксплойт там может не трогай мои данные - и gksu (8) вполне подходит для этого)

— Матия Налис

Все это хорошо, но использование устаревшего и неподдерживаемого двоичного файла SUID просто неправильно. Этот ответ, возможно, был полезен в прошлом, но это больше не так.

— Стефан