qubes-guid fails when started by an RPC from a start-at-boot VM

[anon-user-20180610]

Qubes OS version:

R3.2

Affected component(s):

qrexec-daemon / qubes-guid

Steps to reproduce:

• domX is currently not running
• domY has been started at boot and is currently running
• domY calls an RPC service in domX
• domX is started, but the qubes-guid fails to start
• /var/log/qubes/guid.<domX>.log contains:

No protocol specified
XOpenDisplay: Resource temporarily unavailable

Cause:

This happens because the domX qubes-guid can not read the Xauth token. It is stored in /var/run/lightdm/<user>/xauthority, and this path should normally be communicated via the XAUTHORITY environment variable.

The domX qubes-guid is started (via some intermediate programs) by the domY qrexec-daemon and thus inherits its environment.

But because the domY qrexec-daemon is started at boot, before the dom0 user session is started, its environment does not yet contain XAUTHORITY. So it can not inherit this to the domX qubes-guid, which then can not connect to the X server.

For a quick check in dom0, see how all the start-at-boot VMs lack the XAUTHORITY variable:
for i in $(pgrep qrexec-daemon); do perl -pe 's/\x00/ /g' </proc/$i/cmdline; echo; sudo cat /proc/$i/environ | perl -pe 's/\x00/\n/g' | grep XAUTHORITY; echo; echo; done

Workaround:

qubes-guid tries to read ~/.Xauthority. Making this a symlink to the above mentioned real xauthority file made the problem go away.

Fix:

... sorry, I currently don't have a good idea ...

[marmarek]

It shouldn't be a problem with .Xauthority, because local user is added with xhost command - so have access regardless of Xauthority (see /etc/X11/xinit/xinitrc.d/localuser.sh). But no user process can access X session before user logs in, regardless of method it gets the access later. Maybe that's what you see?

[marmarek]

It shouldn't be a problem with .Xauthority, because local user is added with xhost command - so have access regardless of Xauthority (see /etc/X11/xinit/xinitrc.d/localuser.sh). But no user process can access X session before user logs in, regardless of method it gets the access later. Maybe that's what you see?

[anon-user-20180610]

No, that issue happens even long after logging in.

Also, despite the xhost setting, Xauthority definitely has an effect on the GUI:

$ XAUTHORITY= qvm-run -a work true
Running command on VM: 'work'...
Starting the VM 'work'...
--> Creating volatile image: /var/lib/qubes/appvms/work/volatile.img...
--> Loading the VM (type = AppVM)...
--> Starting Qubes DB...
--> Setting Qubes DB info for the VM...
--> Updating firewall rules...
--> Starting the VM...
--> Starting the qrexec daemon...
Waiting for VM's qrexec agent........connected
--> Starting Qubes GUId...
Connecting to VM's GUI agent: .exiting
ERROR(work): Error while starting the 'work' VM: Cannot start qubes-guid!
$ cat /var/log/qubes/guid.work.log
No protocol specified
XOpenDisplay: Resource temporarily unavailable

Without the XAUTHORITY= prefix, the VM starts up normally.

[anon-user-20180610]

No, that issue happens even long after logging in.

Also, despite the xhost setting, Xauthority definitely has an effect on the GUI:

$ XAUTHORITY= qvm-run -a work true
Running command on VM: 'work'...
Starting the VM 'work'...
--> Creating volatile image: /var/lib/qubes/appvms/work/volatile.img...
--> Loading the VM (type = AppVM)...
--> Starting Qubes DB...
--> Setting Qubes DB info for the VM...
--> Updating firewall rules...
--> Starting the VM...
--> Starting the qrexec daemon...
Waiting for VM's qrexec agent........connected
--> Starting Qubes GUId...
Connecting to VM's GUI agent: .exiting
ERROR(work): Error while starting the 'work' VM: Cannot start qubes-guid!
$ cat /var/log/qubes/guid.work.log
No protocol specified
XOpenDisplay: Resource temporarily unavailable

Without the XAUTHORITY= prefix, the VM starts up normally.

[marmarek]

Maybe something is wrong with that xhost setting? Can you verify if xhost contains SI:localuser:YOUR_USERNAME?

[marmarek]

Maybe something is wrong with that xhost setting? Can you verify if xhost contains SI:localuser:YOUR_USERNAME?

[anon-user-20180610]

I was wondering about that, too, but ...

[XXX@dom0 ~]$ xhost 
access control enabled, only authorized clients can connect
SI:localgroup:qubes
SI:localuser:XXX
[XXX@dom0 ~]$

[anon-user-20180610]

I was wondering about that, too, but ...

[XXX@dom0 ~]$ xhost 
access control enabled, only authorized clients can connect
SI:localgroup:qubes
SI:localuser:XXX
[XXX@dom0 ~]$

[anon-user-20180610]

Can you reproduce that startup problem with XAUTHORITY= qvm-run -a <...> ?

[anon-user-20180610]

Can you reproduce that startup problem with XAUTHORITY= qvm-run -a <...> ?

[marmarek]

No, it works for me.
Hmm, on my system I have also SI:localuser:root in xauth. Maybe that's it? qubes-guid is setuid root.

[marmarek]

No, it works for me.
Hmm, on my system I have also SI:localuser:root in xauth. Maybe that's it? qubes-guid is setuid root.

[marmarek]

BTW I think the only reason left for that setuid root is access to /var/run/shm.id, and that's silly reason. But I might be missing something.

[marmarek]

BTW I think the only reason left for that setuid root is access to /var/run/shm.id, and that's silly reason. But I might be missing something.

[anon-user-20180610]

Funny timing ... I just stumbled across the setuid-root before checking back to this page :-D

I can confirm now that adding SI:localuser:root removes the startup problems with XAUTHORITY= qvm-run ... and solves the original problem.

Thank you very much!

[anon-user-20180610]

Funny timing ... I just stumbled across the setuid-root before checking back to this page :-D

I can confirm now that adding SI:localuser:root removes the startup problems with XAUTHORITY= qvm-run ... and solves the original problem.

Thank you very much!

[andrewdavidwong]

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

[andrewdavidwong]

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.