从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侧面：
  • X使用用户的~/.Xauthority文件复制到/root

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

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

Answer 1

好的，据我所知，我正在编写此答案以尝试阐明X服务器的安全模型。我不是该主题的专家，所以我可能有一些错误（很多？）。而且，正如OP所指出的，在不同的发行版中，甚至在同一发行版的不同版本中，许多事情都是不同的。

有两种主要方法可用来授权连接到X服务器：

• 该xhost办法（ 主机访问 ）：服务器维护被允许连接到服务器主机，本地用户，组，等的列表。
• 该xauth方法（ 基于Cookie ）：服务器随机生成的Cookie的列表，并显示这些饼干的一个人将被授予访问权限。

现在，发行特定的东西…

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

查看您的授权cookie列表。

现在，如果服务器中有任何cookie，则root用户应该能够进行连接，使XAUTHORITY环境变量指向正确的cookie文件。请注意，在许多设置中，登录管理器的cookie也保持不变。只是寻找它！

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

PS：您可以检查与X服务器的root访问权限sudo -i，但要注意，有些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但我不太确定）。或者，您可以使用greeter
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'