Вопрос или проблема
На рабочем столе X я иногда использовал gksudo
или просто sudo somegui
, чтобы запускать графические приложения от имени другого пользователя, включая root. Недавно я обнаружил, что это невозможно на современных (начало 2018 года) рабочих столах Wayland. Все приложения должны запускаться от имени текущего пользователя рабочего стола и ограничены привилегиями этого пользователя.
Это постоянная функция Wayland (предусмотрена по проекту) или использование su-типов улучшений, которое еще не реализовано?
Я ищу документированное заявление (дорожная карта, страница дизайна…), а не предпочтения или мнение.
Это постоянная функция Wayland (предусмотрена по проекту)
Нет. Это не имеет отношения к протоколу wayland. Это скорее вопрос настройки окружения.
Wayland использует сокет, его имя хранится в WAYLAND_DISPLAY
. Он расположен в XDG_RUNTIME_DIR
, который обычно настраивается для доступа только пользователем. Но root тоже может получить к нему доступ. (Некоторые приложения также считают XDG_SESSION_TYPE
, который может иметь значения wayland
или x11
для решения, использовать ли X или Wayland.)
sudo
удаляет большинство переменных окружения, включая XDG_RUNTIME_DIR
и WAYLAND_DISPLAY
.
Вы можете запускать приложения wayland от имени root с помощью:
sudo env XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR WAYLAND_SOCKET=$WAYLAND_SOCKET waylandapplication
или короче с -EH
, чтобы сохранить почти все переменные окружения (но установив HOME
на /root
). Это также включит DISPLAY
и XAUTHORITY
для доступа к Xwayland:
sudo -EH application
Хотя, если приложение, запущенное от имени root, запишет что-либо в XDG_RUNTIME_DIR
, это может вызвать проблемы с разрешением файлов для пользовательских приложений.
Однако, запуск графических приложений от имени root в wayland является гораздо меньшей проблемой с точки зрения безопасности, чем в X11.
Чтобы случайно не использовать X11, вы можете запустить без DISPLAY
:
sudo -EH env DISPLAY= waylandapplication
Я ищу документированное заявление (дорожная карта, страница дизайна…), а не предпочтения или мнение.
Документация Wayland упоминает WAYLAND_DISPLAY
, но я не нахожу ничего о XDG_RUNTIME_DIR
. Однако все композиторы wayland, включая эталонную реализацию weston
, зависят от XDG_RUNTIME_DIR
.
Если бы WAYLAND_DISPLAY
находился в другом месте, это не создавало бы проблем для запуска приложений от произвольных пользователей на одном дисплее wayland. Но XDG_RUNTIME_DIR
указано как ограниченное для вошедшего пользователя и должно содержать сокеты, относящиеся к пользователю:
$XDG_RUNTIME_DIR определяет базовый каталог, относительно которого должны храниться несущественные файлы во время выполнения, относящиеся к пользователю, и другие файловые объекты (например, сокеты, именованные каналы и т. д.). Каталог ДОЛЖЕН принадлежать пользователю, и он ДОЛЖЕН быть единственным, имеющим к нему доступ для чтения и записи. Его режим доступа Unix ДОЛЖЕН быть 0700.
Проблемы с запуском другого пользователя или root в wayland скорее связаны с XDG_RUNTIME_DIR
, нежели с самим wayland. Если вы указываете пользовательский XDG_RUNTIME_DIR
в /tmp
с произвольным доступом (таким образом нарушая его спецификации), все пользователи могут использовать дисплей wayland.
Есть надежда на будущее, чтобы не нуждаться в XDG_RUNTIME_DIR
, но это зависит от реализации: Документация Wayland гл.4:
Начиная с Wayland 1.15, реализации могут по желанию поддерживать конечные точки серверных сокетов, расположенные в произвольных местах в файловой системе, установив WAYLAND_DISPLAY в абсолютный путь, по которому ожидает конечная точка сервера.
Я написал ego
(Alter Ego) для этого случая использования. Это не графическое приложение, но вы можете запускать графические приложения из консоли от имени другого пользователя, оно автоматически обрабатывает xhost и Wayland и совместное использование сокетов PulseAudio: https://github.com/intgr/ego
Трюк заключается в использовании Posix ACLs для предоставления доступа к сокетам Wayland/PulseAudio другому пользователю и настройке переменных окружения, чтобы приложения целевого пользователя знали, как подключиться к ним.
Если возникнут проблемы, пожалуйста, откройте проблему на GitHub.
Есть два довольно простых обходных пути. Примеры ниже запускают synaptic, но любая другая команда подойдет.
- Используя ssh X-Forwarding для root-пользователя (возможно, вам придется включить вход root в
/etc/ssh/sshd_config
или настроить аутентификацию по ключу):
$ ssh -Y root@:: synaptic
- Используя socat & sudo, как предложил bober на RedHat Bug #1274451. Пример ниже предполагает, что мы на дисплее #0, а #1 свободный…
socat UNIX-LISTEN:/tmp/.X11-unix/X1 UNIX-CONNECT:/tmp/.X11-unix/X0 & sudo DISPLAY=:1 synaptic
Я считаю, что в любом случае обходной путь заключается в наличии процесса, принадлежащего пользователю, который подключается к сокету X11 и обеспечивает туннелирование.
Это расширяет ответ Томаса Гуйо-Сионнеста.
Мне кажется, что это заслуживает собственного ответа, так как он решил для меня множество проблем. Создайте оболочный скрипт под названием wlsudo
со следующим содержимым:
#!/usr/bin/env bash
socat UNIX-LISTEN:/tmp/.X11-unix/X1 UNIX-CONNECT:/tmp/.X11-unix/X0 & sudo DISPLAY=:1 "$@"
Сохраните его в каталоге вашего $PATH
и дайте ему права на выполнение (chmod +x ./wlsudo
).
Затем вы сможете запускать графические приложения, используя wlsudo
вместо sudo
в Wayland, например, wlsudo synaptic
просто работает.
Хотя я не отвечаю на ваш вопрос напрямую, я думаю, что есть люди, которые могли оказаться здесь из-за той же проблемы.
Это скрипт, который я сделал, является обходным путем для людей, которым нужно запускать графическое приложение (например, Gedit, Synaptic или GParted) от имени root через sudo в сеансе Wayland:
https://gist.github.com/wachambo/bd22e12db2d5a46dc109bd0d553733be
Импортировано здесь:
#!/usr/bin/env bash
#
# Включить доступ root к x-windows системе.
#
# Мотивация: Попытка запустить графическое приложение от имени root через su, sudo в
# сеансе Wayland (например, GParted или Gedit), провалится. Приложения, которые используют polkit для
# запроса прав администратора только для определенных операций и только тогда, когда это необходимо, не затрагиваются (они не запускаются сразу от имени root).
# [1] https://bugzilla.redhat.com/show_bug.cgi?id=1274451
#
# Основано на комментарии Reddit.
# [2] https://www.reddit.com/r/Fedora/comments/5eb633/solution_running_graphical_app_with_sudo_in/
if (( $# != 1 )); then
echo "Недопустимое количество параметров."
echo
echo "Использование: wsudo [команда]"
exit 1
fi
for cmd in sudo xhost; do
if ! type -P $cmd &>/dev/null; then
echo "$cmd не установлен. Прекращение." >&2
exit 1
fi
done
xhost +SI:localuser:root
sudo $1
#отключить доступ root после завершения работы приложения
xhost -SI:localuser:root
#отобразить статус доступа для проверки, что доступ root был удален
xhost
Простое и прямое решение здесь:
https://unix.stackexchange.com/a/788930/78382
Просто sudo
и переменные окружения wayland, никаких сложных скриптов или запоминания “правильного” способа вызова sudo.
.
Ответ или решение
Wayland, новая графическая система, пришедшая на смену X11, вызвала множество вопросов, связанных с запуском приложений с повышенными привилегиями. В частности, пользователи задаются вопросом, будет ли Wayland поддерживать графический sudo, который был популярен на X11.
Проблематика и контекст:
-
Запуск GUI-приложений с повышенными привилегиями: На X11 можно было использовать
gksudo
или просто запускать команду черезsudo
для выполнения графических приложений от имени другого пользователя, включая root. Это давало гибкость в управлении системой. -
Wayland и ограничение на запуск от имени другого пользователя: На всех современных Wayland окружениях приложения должны запускаться от текущего пользователя, и их привилегии ограничены этой учетной записью. Это вызвало недоумение у пользователей, привыкших к X11.
Почему это происходит:
С точки зрения Wayland, сама по себе графическая среда не ограничивает возможность запуска приложений с правами другого пользователя. Проблема заключена в настройке среды исполнения и её безопасности.
-
Среда и переменные окружения: Wayland использует сокет, имя которого хранится в переменной
WAYLAND_DISPLAY
, а такжеXDG_RUNTIME_DIR
, чтобы ограничить использование ресурсов только текущим пользователем. -
Основные ограничения: Использование
sudo
удаляет большинство переменных окружения, включаяXDG_RUNTIME_DIR
, что мешает приложениям, запущенным от имени другого пользователя, получить доступ к нужному сокету.
Возможные решения и обходные пути:
-
Сохранение переменных окружения: Использование команды
sudo -EH
, которая позволяет сохранить переменные окружения, включаяDISPLAY
иXAUTHORITY
для доступности Xwayland. -
Использование инструментов: Разработка утилит, подобных
ego
, которые автоматически обрабатывают доступ к сокетам Wayland и PulseAudio, предоставляя возможность запускать приложения от имени другого пользователя. -
Создание скриптов: Разработка скриптов, к примеру
wlsudo
, которые могут оборачивать команды с использованиемsocat
иDISPLAY
, чтобы позволить запуск графических приложений через Wayland от имени root. -
Новые возможности Wayland: В более поздних версиях Wayland (начиная с 1.15) появилась поддержка сервера сокетов, расположенных в произвольных местах файловой системы, что может частично решить проблему, если переменная
WAYLAND_DISPLAY
указывает на абсолютный путь.
Заключение:
Текущие ограничения запускать GUI-приложения с повышенными привилегиями в Wayland связаны скорее с используемой файловой и сокетной системой (XDG_RUNTIME_DIR
) и мерами безопасности, чем с самим протоколом Wayland. Более поздние реализации Wayland могут предложить обходные пути, но настоящее решение чаще всего лежит в настройке и использовании инструментов или скриптов, обеспечивающих нужную функциональность.