从 udev 启动的脚本不再具有 DISPLAY 访问权限？

Question

当我插入外部驱动器时，我有一个从 udev 运行的脚本。它总是有效的。但是在从 Linux 3.8/Xorg 1.12/Mint 14（Ubuntu 12.10 兼容）升级到 Linux 3.11/Xorg 1.14/Mint 16（Ubuntu 13.10 兼容），它不再工作了。

脚本仍在运行，但没有任何需要显示的命令起作用。我通过退出 udev 守护进程并手动运行 udevd --debug 以获取详细输出（更多信息见下文）来解决这个问题。

此脚本曾在 Mint 14/12.10 中工作：

export DISPLAY=:0
UUID=$1
DEV=$2

notify-send -t 700 "mounting $DEV ($UUID)"
gnome-terminal -t "Backing up home..." -x rsync long line of data
zenity --warning --text="Done."

但在 Mint 16/13.10 中不再存在。如果您想知道可能的解决方案，我逐渐添加了一些东西，现在看起来像这样：

export DISPLAY=:0.0

xhost +local:
xhost +si:localuser:root
xhost +

DISPLAY=:0.0
export DISPLAY=:0.0
UUID=$1
DEV=$2

notify-send -t 700 "mounting $DEV ($UUID)"
gnome-terminal -t "Backing up home..." -x rsync long line of data
zenity --warning --text="Done." --display=:0.0

但它仍然不起作用。 udevd --debug 仍然显示：

'(err) 'No protocol specified'
'(err) ''
'(err) '** (gnome-terminal:24171): WARNING **: Could not open X display'
'(err) 'No protocol specified'
'(err) 'Failed to parse arguments: Cannot open display: '
'(err) 'No protocol specified'
'(err) ''
'(err) '** (zenity:24173): WARNING **: Could not open X display'
'(err) 'No protocol specified'
'(err) ''
'(err) '(zenity:24173): Gtk-WARNING **: cannot open display: :0.0'
'(err) 'No protocol specified'

请注意，任何 bash 逻辑都有效。将测试变量回显到>>/tmp/test.log 有效。它只是访问不再工作的显示。

这快把我逼疯了。现在实现这一目标的正确方法是什么？

2013 年 12 月 20 日更新

因此，在之前的 Ubuntu 中，X 命令会使用用户自动找到通往当前X 的路径。

现在，我似乎每次都需要这两件事：

• 在X 上使用用户：
  • xhost +si:localuser:root
• 在root/udev 方面：
  • 使用用户的~/.Xauthority文件将X复制到/root

这“感觉”就像是时光倒流。这仅在我每次以同一用户身份登录时脚本化才有效，因此我可以在脚本执行时从该用户的家中复制 .Xauthority 文件。

旧的 Ubuntu 使用了什么“技巧”来自动“神奇”地完成这项工作？

Answer 1

好的，我写这个答案是为了尝试澄清 X 服务器的安全模型，据我所知。我不是这方面的专家，所以我可能弄错了一些（很多？）事情。此外，正如 OP 所指出的，在不同的发行版中，甚至同一发行版的不同版本中，许多事情都是不同的。

获得授权连接到 X 服务器的主要方法有两种：

• xhost 方式（主机访问）：服务器维护一个允许连接到服务器的主机、本地用户、组等的列表。
• xauth 方式（基于 Cookie）：服务器有一个随机生成的 cookie 列表，任何显示其中一个 cookie 的人都将被授予访问权限。

现在，分配特定的东西......

X 服务器由启动系统启动时，通常会传递-auth <filename> 形式的命令行。此文件包含用于授权的初始 cookie 列表。它是在 X 服务器运行之前使用xauth 工具创建的。然后就在 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

查看您的授权 cookie 列表。

现在，如果服务器中有任何 cookie，root 用户应该能够连接，使 XAUTHORITY 环境变量指向正确的 cookie 文件。请注意，在许多设置中，登录管理器的 cookie 也被保留。随便找！

root 访问的另一种可能性是修改Xsession 文件以添加命令xhost +si:localuser:root 并获得永久访问权限。具体细节因使用的特定程序而异，但对于gdm，您只需使用xhost 命令在/etc/gdm/Init/ 中添加一个可执行脚本，它将在下次启动时自动运行。

PS：您可以使用sudo -i检查您对X服务器的root访问权限，但请注意，某些sudo配置可能会保留DISPLAY、XAUTHORITY或HOME变量并修改测试结果.

示例：此脚本应该能够以 root 身份将您连接到 X 服务器

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

当然，XAUTHORITY 变量的路径取决于您使用的登录管理器（问候语）。你可以使用用户文件（你说它在/home/redsandro/.Xauthority，但我不太确定）。或者，您可以使用欢迎 cookie。要获取欢迎 cookie，您可以使用以下命令：

$ 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。 gDg3Ij 是随机的，每次服务器重新启动时都会发生变化，这就是 ls ... 技巧的原因。

使用 GDM cookie 代替用户的好处是它不依赖于登录的用户。它甚至可以在没有用户的情况下工作！

更新：从您的最新评论中，我看到您的 X 服务器命令是：

/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'

Answer 2

快速搜索发现以下内容：

X 身份验证基于 cookie —— 秘密的随机小片段 只有你和 X 服务器知道的数据……所以，你需要让 其他用户了解您的 cookie 是什么。一种方法是 遵循：在您发出 su 或 sudo 之前（但在 ssh 进入 远程系统，如果您使用 ssh），请求 cookie 当前正在连接到 X 服务器的 DISPLAY：

$ xauth list $DISPLAY 你会得到类似的东西

somehost.somedomain:10 mit-magic-cookie-1 4d22408a71a55b41ccd1657d377923ae

然后，在完成 su 之后，告诉新用户 cookie 是什么：

$ xauth add somehost.somedomain:10 MIT-MAGIC-COOKIE-1 4d22408a71a55b41ccd1657d377923ae

（只需将上述“xauth 列表”的输出复制并粘贴到“xauth”中 添加'）就是这样。现在，您应该可以启动任何 X 应用程序了。

供参考，这里是出处http://www.linuxquestions.org/questions/linux-newbie-8/xlib-connection-to-0-0-refused-by-server-xlib-no-protocol-specified-152556/

Answer 3

这并不漂亮，但我还没有看到任何解决方案。所以这是迄今为止最好的。

• 在X 上使用用户：
  • xhost +si:localuser:root
• 在 root/udev 端：
  • 使用用户的~/.Xauthority 文件将X 复制到/root（* 请参阅下面的注释）

现在可以了。试试zenity --warning --text=Hooray

这仅在您知道哪个用户将要登录 X 时才有效。因此，仅当计算机由具有单个用户帐户的单个用户使用时才可接受。

*) 注意
这是值得注意的，因为我尝试了xauth merge /home/redsandro/.Xauthority 和$XAUTHORITY=/home/redsandro/.Xauthority 的记录方法。这些记录在案的方法现在什么都不做，即使root 有权阅读它。您需要从字面上看整个 .Xauthority 文件，而不是仅仅指向它。

Answer 4

较新版本的 Ubuntu 使用不同的显示管理器，因此您必须知道您使用的是哪一个。 在 Rodrigo 的帖子中，有一个提示显示如何使用以下命令发现它：

ls /var/run/gdm/auth-for-gdm-*/database

要检查这一点，请列出 /var/run 目录并使用“pgrep -a Xorg”命令。 在 Ubuntu 16* 中，它使用 sddm，因此，您可以使用

ls /var/run/sddm* 导出 XAUTHORITY 变量。

脚本是这样的：

#!/bin/bash
export DISPLAY=:0
export XAUTHORITY=`ls /var/run/sddm*`
HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)"
USER="your username"
export XAUTHORITY=/home/$USER/.Xauthority
export DISPLAY=:0

if [ "$HDMI_STATUS" = connected ];
then
sudo -u $USER pactl set-card-profile 0 output:hdmi-stereo+input:analog-stereo
else
sudo -u $USER pactl set-card-profile 0 output:analog-stereo+input:analog-stereo
fi
exit 0

然后运行：

sudo chmod 755 /usr/local/bin/toggle-sound

echo 'ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/toggle-sound"' | sudo tee /etc/udev/rules.d/99-hdmi-sound.rules

sudo udevadm control --reload-rules

Answer 5

我必须在 Kali Linux 2016 中使用它才能让它工作：

#!/bin/bash
set -x
xhost local:root
export DISPLAY=:0.0
su root -c 'zenity --notification --text="I am a notification!"'

Answer 6

如果直接从 udev 调用脚本不起作用，为什么不启动一个调用该脚本的 systemd 服务？

这是我的解决方案：

首先是在拔出具有 ID_PART_ENTRY_UUID 的设备（或分区）时运行 media-storage-unplugged.service 的 udev 规则

/etc/udev/rules.d/storage-unplugged.rules：

ACTION=="remove", KERNEL=="sd[a-z][0-9]", ENV{ID_PART_ENTRY_UUID}=="replace-with-your-uuid", SYMLINK+="storage", RUN+="/usr/bin/systemctl --no-block start media-storage-unplugged.service"

/etc/systemd/system/media-storage-unplugged.service：（服务文件）

[Unit]
Description=Triggered when storage is unplugged

[Service]
Type=oneshot
ExecStart=/usr/local/bin/storage_unplugged

[Install]
WantedBy=multi-user.target

/usr/local/bin/storage_unplugged（在这里发挥创意）

#!/bin/bash
notify-send-to-user "storage unplugged"
exit 0

/usr/local/bin/notify-send-to-user

#!/bin/bash

function ns() {
    #Detect the name of the display in use
    local display=":$(ls /tmp/.X11-unix/* | sed 's#/tmp/.X11-unix/X##' | head -n 1)"

    #Detect the user using such display (NOTE: Didn't work on Arch linux since the "who" command doesn't show which display the user is using)
    #local user=$(who | grep '('$display')' | awk '{print $1}' | head -n 1)
    #Statically assign user:
    local user="user" # Replace with your user

    #Detect the id of the user
    local uid=$(id -u $user)

    sudo -u $user DISPLAY=$display DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus notify-send "$@"
}

ns "$@"

根据您的需要调整此方法:)