Будет ли Wayland когда-нибудь поддерживать графический режим sudo?

Вопрос или проблема

На рабочем столе 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, но любая другая команда подойдет.

  1. Используя ssh X-Forwarding для root-пользователя (возможно, вам придется включить вход root в /etc/ssh/sshd_config или настроить аутентификацию по ключу):
$ ssh -Y root@:: synaptic
  1. Используя 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.

Проблематика и контекст:

  1. Запуск GUI-приложений с повышенными привилегиями: На X11 можно было использовать gksudo или просто запускать команду через sudo для выполнения графических приложений от имени другого пользователя, включая root. Это давало гибкость в управлении системой.

  2. Wayland и ограничение на запуск от имени другого пользователя: На всех современных Wayland окружениях приложения должны запускаться от текущего пользователя, и их привилегии ограничены этой учетной записью. Это вызвало недоумение у пользователей, привыкших к X11.

Почему это происходит:

С точки зрения Wayland, сама по себе графическая среда не ограничивает возможность запуска приложений с правами другого пользователя. Проблема заключена в настройке среды исполнения и её безопасности.

  • Среда и переменные окружения: Wayland использует сокет, имя которого хранится в переменной WAYLAND_DISPLAY, а также XDG_RUNTIME_DIR, чтобы ограничить использование ресурсов только текущим пользователем.

  • Основные ограничения: Использование sudo удаляет большинство переменных окружения, включая XDG_RUNTIME_DIR, что мешает приложениям, запущенным от имени другого пользователя, получить доступ к нужному сокету.

Возможные решения и обходные пути:

  1. Сохранение переменных окружения: Использование команды sudo -EH, которая позволяет сохранить переменные окружения, включая DISPLAY и XAUTHORITY для доступности Xwayland.

  2. Использование инструментов: Разработка утилит, подобных ego, которые автоматически обрабатывают доступ к сокетам Wayland и PulseAudio, предоставляя возможность запускать приложения от имени другого пользователя.

  3. Создание скриптов: Разработка скриптов, к примеру wlsudo, которые могут оборачивать команды с использованием socat и DISPLAY, чтобы позволить запуск графических приложений через Wayland от имени root.

  4. Новые возможности Wayland: В более поздних версиях Wayland (начиная с 1.15) появилась поддержка сервера сокетов, расположенных в произвольных местах файловой системы, что может частично решить проблему, если переменная WAYLAND_DISPLAY указывает на абсолютный путь.

Заключение:

Текущие ограничения запускать GUI-приложения с повышенными привилегиями в Wayland связаны скорее с используемой файловой и сокетной системой (XDG_RUNTIME_DIR) и мерами безопасности, чем с самим протоколом Wayland. Более поздние реализации Wayland могут предложить обходные пути, но настоящее решение чаще всего лежит в настройке и использовании инструментов или скриптов, обеспечивающих нужную функциональность.

Оцените материал
Добавить комментарий

Капча загружается...