小编典典

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

linux

我有一个脚本,该脚本从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使用了什么“技巧”来自动“神奇地”完成这项工作?


阅读 428

收藏
2020-06-07

共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配置可能会保留DISPLAYXAUTHORITYHOME变量和修改测试的结果。

示例 :该脚本应该能够以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'
2020-06-07