从udev启动的脚本不再具有DISPLAY访问权限了吗? [英] Scripts launched from udev do not have DISPLAY access anymore?

问题描述

当插入外部驱动器时，我有一个从udev运行的脚本.一直有效.但是从 Linux 3.8/Xorg 1.12/Mint 14 (兼容 Ubuntu 12.10 )升级到 Linux 3.11/Xorg 1.14/Mint 16 ( Ubuntu 13.10 兼容)，它不再起作用.

I have a script that runs from udev when I plug in my external drive. It always worked. But after upgrading from Linux 3.8/Xorg 1.12/Mint 14 (Ubuntu 12.10 compatible) to Linux 3.11/Xorg 1.14/Mint 16 (Ubuntu 13.10 compatible), it doesn't work anymore.

该脚本仍在运行，但是没有任何需要显示工作的命令.我通过退出udev守护程序并手动运行udevd --debug进行详细输出(下文中有更多内容)来弄清了这一点.

The script still runs, but none of the commands that require the display work. I figured that out by quitting the udev daemon and manually run udevd --debug for verbose output (more below).

此脚本曾经在薄荷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."

但在薄荷16/13.10 中不再可用.如果您想知道可能的解决方案，我会逐渐添加一些东西，现在看起来像这样:

But not anymore in Mint 16/13.10. In case you are wondering about possible solutions, I gradually added stuff and now it looks like this:

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仍然显示以下内容:

But it still doesn't work. udevd --debug still shows this:

'(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相呼应.只是访问不再起作用的显示器.

Note that any bash logic works. Echoing test vars to >>/tmp/test.log works. It's just accessing the display that does not work anymore.

这让我发疯.现在实现此目标的正确方法是什么?

This is driving me crazy. What is the correct way to achieve this now?

因此，在以前的Ubuntu中，X命令将使用用户自动找到通向当前X的方式.

So, in the previous Ubuntu, X commands would automatically find it's way to the current X using user.

现在，我似乎每次都需要这两个东西:

Now, I seem to need these two things every time:

• 在使用用户的X上:
  • xhost +si:localuser:root
  • On the X using user:
    • xhost +si:localuser:root
    • 使用用户的~/.Xauthority文件将X复制到/root
    • Copy X using users' ~/.Xauthority file to /root

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

    This 'feels' like a step back in time. This only works scripted when I log in as the same user everytime, so I can copy the .Xauthority file from that users' home when the script executes.

    旧版Ubuntu使用了哪些技巧"来自动神奇地"完成这项任务?

    What 'trick' did the old Ubuntu use to have this done auto'magic'ally?

    推荐答案

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

    Ok, I'm writing this answer to try and clarify the security model of the X server, as I understand it. I'm not an expert on the subject, so I may have got some (many?) things wrong. Also, many things are different in different distributions, or even different versions of the same distribution, as the OP noted.

    有两种主要的方法可以授权连接到X服务器:

    There are two main ways to get authorized to connect to the X server:

    • xhost方式(主机访问):服务器维护允许连接到服务器的主机，本地用户，组等的列表.
    • xauth方式(基于 Cookie ):服务器上有随机生成的cookie列表，任何显示这些cookie之一的人都将被授予访问权限.
    • The xhost way (Host Access): The server maintains a list of hosts, local users, groups, etc. that are allowed to connect to the server.
    • The xauth way (Cookie based): The server has a list of randomly generated cookies, and anybody showing one of these cookies will be granted access.

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

    Now, the distribution specific stuff...

    当X服务器由启动系统启动时，通常会通过-auth <filename>形式的命令行来传递.该文件包含用于授权的初始cookie列表.它是在使用xauth工具运行X服务器之前创建的.然后，在X服务器之后，启动登录管理器，并指示它从同一文件读取cookie，以便它可以连接.

    When the X server is launch by the start-up system, it is usually passed a command line of the form -auth <filename>. This file contains a list of initial cookies to be used for authorization. It is created before the X server is run using the xauth tool. Then just after the X server, the login manager is launch, and it is instructed to read the cookie from this same file, so it can connect.

    现在，当用户rodrigo登录时，必须被授权连接到服务器.这是由登录管理器完成的，它有两个选项:

    Now, when user rodrigo logs in, it has to be authorized to connect to the server. That is done by the login manager, and it has two options:

    • 它等效于:xhost +si:localuser:rodrigo.
    • 它生成另一个cookie，将其添加到服务器并将其传递给用户.可以通过两种方式完成此传递:
      • 它写在文件$HOME/.Xauthority(新用户的主页)中.
      • 它写在其他地方(/var/run/gdm/auth-for-rodrigo-xxxx)，并且环境变量XAUTHORITY设置为该文件的名称.
      • It does the equivalent to: xhost +si:localuser:rodrigo.
      • It generates another cookie, adds it to the server and passes it to the user. This passing can be done in two ways:
        • It is written in the file $HOME/.Xauthority (home of the new user).
        • It is written somewhere else (/var/run/gdm/auth-for-rodrigo-xxxx) and the environment variable XAUTHORITY is set to the name of that file.

        此外，它可以做两件事.某些登录管理器甚至默认情况下将root用户添加到授权用户列表中(就像xhost +si:localuser:root一样).

        Also, it can do both things. Some login managers even add the root user to the list of authorized users by default (as if xhost +si:localuser:root).

        但是请注意，如果您无权连接到X服务器，则无法将自己添加到列表中(例如，运行xhost +).原因与为什么没有钥匙就无法从外面打开屋檐的原因相同.即使您是root，也是如此！

        But note that if you are not authorized to connect to the X server, you cannot add yourself to the list (running xhost + for example). The reason is the same as why you cannot open a house doof from the outside without a key... That's true even if you are root!

        这是否意味着root用户无法连接到服务器?绝对不！但是首先，您必须知道如何将登录用户配置为连接到服务器.对于以登录用户身份运行的用户:

        Does it mean that the root user cannot connect to the server? Absolutely not! But to get to that first you have to know how is the logged user configured to connect to the server. For that run as the logged user:

        $ xhost
        

        它将显示一条消息以及授权的用户，主机或组的列表，如果有的话:

        It will show a message and the list of authorized users, hosts or groups, if any:

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

        然后运行:

        $ echo $XAUTHORITY
        

        查看授权文件的保存位置.如果为空，则为~/.Xauthority.然后:

        To see where the authorization file is saved. If it is empty, then it will be ~/.Xauthority. Then:

        $ xauth list :0
        

        要查看您的授权cookie列表.

        To see the list of your authorized cookies.

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

        Now, if there are any cookie in the server, the root user should be able to connect making the XAUTHORITY environment variable point to the right cookie file. Note that in many setups, the cookie of the login manager is also kept around. Just look for it!

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

        Another possibility for root access is to modify the Xsession files to add the command xhost +si:localuser:root and get permanent access. The details vary with the particular program used, but for gdm you would simply add an executable script in /etc/gdm/Init/ with the xhost command and it will be run automatically in the next boot.

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

        PS: You can check your root access to the X server with sudo -i, but note that some sudo configurations may keep the DISPLAY, XAUTHORITY or HOME variables and modify the results of the tests.

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

        EXAMPLE: This script should be able to connect you to the X server as root

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

        自然，XAUTHORITY变量的路径将取决于您使用的登录管理器(问候语).您可以使用用户文件(您说它在/home/redsandro/.Xauthority中，但我不太确定).或者，您可以使用greeter cookie.要获取问候cookie，可以使用以下命令:

        Naturally, the path for the XAUTHORITY variable will depend on what login manager you are using (greeter). You can use the user file (you say it is in /home/redsandro/.Xauthority but I'm not so sure). Or you can use the greeter cookie. To get the greeter cookie you can use the following command:

        $ 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 ...窍门的原因.

        So my file is /var/run/gdm/auth-for-gdm-gDg3Ij/database. The gDg3Ij is random and changes every time the server is restarted, that's why the ls ... trick.

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

        The nice thing of using the GDM cookie instead of the user is that it does not depend on the user logged in. It will even work with no user at all!

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

        UPDATE: From your latest comment I see that your X server command is:

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

        因此存在用于启动登录管理器的cookie的名称.如果我是对的，那么只要您能够读取文件，该文件就应该一直可用.而且您是root用户，因此以下几行足以让您以root用户身份访问显示内容:

        So there is the name of the cookie used to start the login manager. If I'm correct, that should be available all the time, if you are able to read the file. And you are root, so, the following lines should be enough to get you access to the display as root:

        export DISPLAY=:0
        export XAUTHORITY=/var/lib/mdm/:0.Xauth
        
        zenity --info --text 'Happy New Year'
        

        这篇关于从udev启动的脚本不再具有DISPLAY访问权限了吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！