我有一个脚本,该脚本从udev插入外部驱动器时开始运行。一直有效。但是在从 Linux 3.8 / Xorg 1.12 / Mint 14 (与 Ubuntu 12.10 兼容)升级到 Linux 3.11 / Xorg 1.14 / Mint 16 (与 Ubuntu 13.10 兼容)之后,它不再起作用。
udev
该脚本仍在运行,但是没有任何需要显示的命令。我通过退出udev守护程序并手动运行udevd --debug以获取详细输出来了解这一点(更多信息请参见下文)。
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。它只是访问不再起作用的显示。
>>/tmp/test.log
这真让我抓狂。现在实现此目标的正确方法是什么?
因此,在先前的Ubuntu中,X命令会自动找到通向当前X使用用户的方式。
X
现在,我似乎 每次都 需要这两件事:
xhost +si:localuser:root
root/udev
~/.Xauthority
/root
这种“感觉”就像是时光倒流。仅当我每次以同一用户身份登录时,此脚本才有效,因此.Xauthority在执行脚本时,可以从该用户的家中复制文件。
.Xauthority
旧的Ubuntu使用了什么“技巧”来自动“神奇地”完成这项工作?
好的,据我所知,我正在编写此答案以尝试阐明X服务器的安全模型。我不是该主题的专家,所以我可能有一些错误(很多?)。而且,正如OP所指出的,在不同的发行版中,甚至在同一发行版的不同版本中,许多事情都是不同的。
有两种主要方法可用来授权连接到X服务器:
xhost
xauth
现在,发行特定的东西…
当X服务器由启动系统启动时,通常会通过形式的命令行来传递-auth <filename>。该文件包含用于授权的初始cookie列表。它是在使用该xauth工具运行X服务器之前创建的。然后,在X服务器之后,启动登录管理器,并指示其从同一文件读取cookie,以便它可以连接。
-auth <filename>
现在,当用户rodrigo登录时,必须被授权连接到服务器。这是由登录管理器完成的,它有两个选项:
rodrigo
xhost +si:localuser:rodrigo
$HOME/.Xauthority
/var/run/gdm/auth-for-rodrigo-xxxx
XAUTHORITY
而且,它可以同时做两件事。某些登录管理器甚至默认情况下将root用户添加到授权用户列表中(就像xhost +si:localuser:root)。
但是请注意,如果您无权连接到X服务器,则无法将自己添加到列表中(xhost +例如,正在运行)。原因与为什么没有钥匙就无法从外面打开屋檐的原因相同,即使您是root,也是如此!
xhost +
这是否意味着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命令中添加可执行脚本,它将在下次启动时自动运行。
Xsession
gdm
/etc/gdm/Init/
PS:您可以检查与X服务器的root访问权限sudo -i,但要注意,有些sudo配置可能会保留DISPLAY,XAUTHORITY或HOME变量和修改测试的结果。
sudo -i
sudo
DISPLAY
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,可以使用以下命令:
/home/redsandro/.Xauthority
$ 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 ...窍门的原因。
/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'