Can I launch a graphical program on another user's desktop as root?

Question

Following are other questions which I think I need to know:

• From a non X Session? (meaning root isn't logged into X)

• If multiple people were logged in on X, could I auto-detect who was on which screen, and thus programmatically detect which screen I need to launch the app on?

• Can I launch the app as the user? ( ok I'm 99.999% sure this is a yes )

• Can I detect if users of group X are logged in to X?

Solution 1

To launch a graphical program on a user's desktop, you need to find two things: what display the user's desktop is on (the address) and what authorization cookie to use (the password).

The following command should list the local displays that the user is logged on (one per line) on most unices:

who | awk -v user="$target_user" '$1 == user && $2 ~ "^:" {print $2}'

Finding the authorization cookie is a little harder. You have to look for the user's cookie file, which is ~/.Xauthority by default (all you need is the location of the cookie file, you don't need to extract the cookie from it). That works on many systems, but not all; it depends on the display manager and how it's set up, and in particular Gdm (the default on Ubuntu) did not use the default location last I looked. I can't think of a portable way to find out the actual X cookie file. The most accurate way to find out is to find out the pid of the X process and look for the argument to the -auth option. Another way is to find a process running on that X server and grab its XAUTHORITY environment variable. If you have trouble finding the cookie file, see Open a window on a remote X display (why "Cannot open display")?

Once you have both pieces of information, put the chosen display in the DISPLAY environment variable, the chosen X authority cookie file in the XAUTHORITY environment variable, and you're set. It doesn't matter what user the program runs as; combine with su if you like.

Solution 2

I can't completely try this since all my machines have root disabled.

To find which display a user is on, you can use the who command. The last column of output is usually the DISPLAY that the user is logged in on. Something like this could be used to grab just the display (there is likely a far more efficient way to do this, feel free to offer edits):

who | grep -m1 ^username.*\( | awk '{print $5}' | sed 's/[(|)]//g'

Then to launch a graphical X command on that display:

DISPLAY=:0 firefox &

where :0 would be replaced with whatever display you found in the first command and firefox would be replaced with whatever command you want to run. You could put this in a shell script and just use a variable.

The next part is the part I haven't tested, but I don't see why it shouldn't be possible to do:

su username -c "DISPLAY=:0 firefox"

to launch the X command as that user.

Solution 3

You could look at how acpid does it. E.g. when it issues xscreensaver commands or blanks the screen for each user running X or X-session.

For example under Ubuntu this file contains related stuff:

/etc/acpi/lid.sh

Contains this loop:

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        grep -q off-line /proc/acpi/ac_adapter/*/state
        if [ $? = 1 ]
            then
            if pidof xscreensaver > /dev/null; then 
                su $user -c "xscreensaver-command -unthrottle"
            fi
        fi
        if [ x$RADEON_LIGHT = xtrue ]; then
            [ -x /usr/sbin/radeontool ] && radeontool light on
        fi
        if [ `pidof xscreensaver` ]; then
            su $user -c "xscreensaver-command -deactivate"
        fi
        su $user -c "xset dpms force on"
    fi
done

Solution 4

An extension to Gilles answer is how to find the cookie file. One way to do it may be after you set the DISPLAY environment variable (as described by Gilles), use strace to find the files xhost access. I can think of something like this in BASH:

# Set the DISPLAY variable first
DISPLAY = :0.0
# Use strace on xhost
strace xhost 2>&1 | grep access

The output from the code above will look like:

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
access("/home/someuser/.Xauthority", R_OK) = 0

As you can clearly see, the cookie file will directly appear here.

View more solutions

Comments

[xenoterracide]

Just because root is disabled doesn't mean stuff doesn't get run as root ;) I actually need to run this as a script that's running as root.

[Steven D]

@xenoterracide, right. All I meant was that I couldn't test it under all possible circumstances. That is, I only tested it as root using sudo -i and couldn't be sure if the results would be different than running it after logging in as root directly. :-)

[xenoterracide]

I had to modify the who a bit. This who | grep xeno| awk '{print $5}' | sed 's/[(|)]//g' | grep -v ^$ seems to work...

[Gilles 'SO- stop being evil']

Specifically, the code is in /usr/share/acpi-support/power-funcs. It calls fgconsole to find the active Linux vt, then looks for an X server displaying on this console, and finds out the user from there. Then it uses ~/.Xauthority as the X cookie, which unless there's something I'm missing means that it won't actually be able to connect to the X server (Ubuntu's default setup, using gdm, doesn't store the X cookies in the user's home directory).

[maxschlepzig]

@Gilles lid.sh for example does not call getXconsole. Thus, fgconsole is not used. I updated the answer with the snippet I've had in mind. And it actually works on Ubuntu. Screen is blanked when I close the lid.

[Admin]

why anyone uses grep and sed when there is already awk in the chain is beyond me.

[Steven D]

yeah..."learn awk" has been on my todo list for a while now.

[rubo77]

How do your "look for the argument to the -auth option"?

[Gilles 'SO- stop being evil']

@rubo77 With ps or htop or …

[rubo77]

OK, so pids=$(pgrep -u $target_user nautilus) gets the pid, and where do I have to put an -auth option?

[Gilles 'SO- stop being evil']

@rubo77 You don't put a -auth option anywhere. You may need to look for it in the X server process's command line to figure out what to put in the XAUTHORITY environment variable. If you have the process of a client, what you need is not anything about -auth but the value of that client's XAUTHORITY variable. I don't understand what you're trying to do. You may want to ask a new question.

[rubo77]

In ubuntu 14.04 I get the error getXuser: command not found

[rubo77]

I try to use your information here to solve how to Create a notification on the screen initiated by root

[akavel]

On Ubuntu 16.04, this worked for me in ssh session: sudo -u $OTHER_USER -i bash -c "XAUTHORITY=/home/$OTHER_USER/.Xauthority DISPLAY=:0 xterm"

[Gilles 'SO- stop being evil']

@akavel What display manager are you using? IIRC under Ubuntu (at least older releases of Ubuntu) Gdm uses a different cookie file, but other display managers and startx use the default location.

[akavel]

@Gilles I believe it's lightdm; anyway the default one when installing "Desktop Ubuntu" apparently

[Dmitry Grigoryev]

I suggest you make it crystal-clear that you're the author of this xpub script.