Скрипты, запущенные из udev, больше не имеют доступа к дисплею?

хорошо, я пишу этот ответ, чтобы попытаться прояснить модель безопасности X-сервера, как я ее понимаю. Я не эксперт по этому вопросу, поэтому у меня, возможно, есть некоторые (многие? все не так. Кроме того, многие вещи различаются в разных дистрибутивах или даже в разных версиях одного и того же дистрибутива, как отметил ОП.

существует два основных способа получить разрешение на подключение к X-серверу:

• на xhost путь (Доступ К Узлу): в сервер поддерживает список хостов, Локальные пользователи, группы и т. д. которые могут подключаться к серверу.
• на xauth путь (Cookie на основе): на сервере есть список случайно сгенерированных куки, и любой, кто показывает один из этих куки будет предоставлен доступ.

теперь, распределение конкретных вещей...

когда X-сервер запускается системой запуска, ему обычно передается командная строка формы -auth <filename>. Этот файл содержит список исходных файлов cookie для авторизации. Он создается до запуска X-сервера с помощью . Затем сразу после X-сервера запускается менеджер входа в систему, и ему поручено прочитать файл cookie из этого же файла, чтобы он мог подключиться.

теперь, когда пользователь rodrigo входит в систему, он должен быть авторизован для подключения к серверу. Это делается менеджером входа в систему, и у него есть два варианта:

• это эквивалентно: xhost +si:localuser:rodrigo.
• он генерирует другой файл cookie, добавляет его на сервер и передает Пользователю. Этот переход можно сделать двумя способами:
  • это написано в файле $HOME/.Xauthority (главная страница нового пользователя).
  • написано где-то в другом месте (/var/run/gdm/auth-for-rodrigo-xxxx) и переменная окружения XAUTHORITY имеет значение имя этого файла.

кроме того, он может делать обе вещи. Некоторые менеджеры входа даже добавляют пользователя root в список авторизованные пользователи по умолчанию (как будто xhost +si:localuser:root).

но обратите внимание, что если вы не авторизованы для подключения к X-серверу, вы не можете добавить себя в список (работает xhost + например). Причина та же, почему вы не можете открыть дом снаружи без ключа... Это правда, даже если вы root!

это значит, что пользователь root не может подключиться к серверу? Абсолютно нет! Но чтобы дойти до этого сначала вы должны знать, как пользователя настроена для подключения к серверу. Для этого запустите от имени зарегистрированного пользователя:

$ xhost

он покажет сообщение и список авторизованных пользователей, хостов или групп, если таковые имеются:

access control enabled, only authorized clients can connect
SI:localuser:rodrigo

запустите:

$ echo $XAUTHORITY

чтобы увидеть, где файл авторизации сохраняется. Если он пуст, то он будет ~/.Xauthority. Затем:

$ xauth list :0

чтобы увидеть список ваших авторизованных cookies.

теперь, если есть какие-либо cookie на сервере, пользователь root должен быть в состоянии подключиться, делая переменную среды XAUTHORITY точкой в правом файле cookie. Обратите внимание, что во многих настройках файл cookie диспетчера входа также сохраняется. Просто ищи его!

еще одна возможность для корневого доступа-изменить Xsession файлы для добавления команды xhost +si:localuser:root и получить постоянный доступ. Детали варьируются в зависимости от конкретной используемой программы, но для gdm вы просто добавите исполняемый скрипт в /etc/gdm/Init/ С и это будет запускаться автоматически при следующей загрузке.

PS: вы можете проверить корневой доступ к X-серверу с sudo -i, но обратите внимание, что некоторые хранить DISPLAY, XAUTHORITY или HOME переменные и изменить результаты тестов.

пример: этот скрипт должен иметь возможность подключить вас к X-серверу как root

export DISPLAY=:0
export XAUTHORITY=`ls /var/run/gdm/auth-for-gdm-*/database`
xrandr #just for show

естественно, путь к XAUTHORITY переменная будет зависеть от того, какой менеджер входа вы используя (зазывала). Вы можете использовать файл пользователя (вы говорите, что он находится в /home/redsandro/.Xauthority но я не уверен). Или вы можете использовать печенье greeter. Чтобы получить приглашение печенья вы можете использовать следующую команду:

$ pgrep -a Xorg

что в моей системе дает:

408 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-gDg3Ij/database -seat seat0 -nolisten tcp vt1

мой файл /var/run/gdm/auth-for-gdm-gDg3Ij/database. The gDg3Ij является случайным и изменяется каждый раз при перезапуске сервера, поэтому ls ... трюк.

хорошая вещь использования файла cookie GDM вместо пользователя заключается в том, что он делает не зависит от пользователя. Он даже не будет работать с пользователем вообще!

обновление: из вашего последнего комментария я вижу, что ваша команда X server:

/usr/bin/X :0 -audit 0 -auth /var/lib/mdm/:0.Xauth -nolisten tcp vt8

таким образом, есть имя файла cookie, используемого для запуска диспетчера входа. Если я прав, это должно быть доступно все время, если вы можете прочитать файл. И вы root, поэтому следующих строк должно быть достаточно, чтобы получить доступ к дисплею как root:

export DISPLAY=:0
export XAUTHORITY=/var/lib/mdm/:0.Xauth

zenity --info --text 'Happy New Year'