Update RPC does not work in debian-8 / missing $DISPLAY when running RPC as root

[Vít Šesták]

It seems I've violated some Qubes assumption. When I try to update debian-8 template via qubes-manager, it does nothing.

I've tried to debug a bit:

$ qvm-run -a -p -u root debian-8 /etc/qubes-rpc/qubes.InstallUpdatesGUI
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set


Ha, $DISPLAY is missing. I haven't messed with sudo in this VM, but anyway, it works well with sudo:

$ qvm-run -a -p -u root debian-8 'env | grep DISPLAY'
$ qvm-run -a -p -u user debian-8 'env | grep DISPLAY'
DISPLAY=:0
$ qvm-run -a -p -u user debian-8 'sudo env | grep DISPLAY'
DISPLAY=:0
$ qvm-run -a -p -u user debian-8 'su -c env | grep DISPLAY'
su: must be run from a terminal

Hmm, not sure where the restriction could come from. When listing full env output, both sudo and “-u root” variants are somewhat stripped (e.g., QUBES_KEYMAP is missing), but sudo's environment is stripped a bit less.

Where to look next?

Regards,
Vít Šesták 'v6ak'

[Chris Laprise]

This works correctly for me, even with a completely unmodified debian-8
template.

Have you made modifications which might suppress setting of DISPLAY for
root?

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Unman]

Chris is right - it works as expected with vanilla and my custom Debian templates.

[Vít Šesták]

I am not aware of any change that could have affected it. And I have no further ideas what to check. 😔

Regards,
Vít Šesták 'v6ak'

[Chris Laprise]

Only other variables I can think of: I'm using a 4.9.28 kernel and a VPN
proxyVM. Also, Apparmor is enabled.

[Vít Šesták]

I have the same kernel version, AppArmor default (haven't bothered about it) and VM connected to sys-firewall.

To make it even more strange, when I changed the command to run in a debian-8-based AppVM instead of the debian-8 itself, I realized there is some VM it works in. But it does not work in some other VMs based on the template. I have no idea why it behaves this way…

Regards,
Vít Šesták 'v6ak'

[Chris Laprise]

On 06/07/2017 12:31 PM, Vít Šesták wrote:
> I have the same kernel version, AppArmor default (haven't bothered about it) and VM connected to sys-firewall.
>

To clarify, apparmor is enabled in kernelopts, but not inside the
template. I doubt its affecting this issue, though.

> To make it even more strange, when I changed the command to run in a debian-8-based AppVM instead of the debian-8 itself, I realized there is some VM it works in. But it does not work in some other VMs based on the template. I have no idea why it behaves this way…
>

Sounds like it might be a race condition...

[Vít Šesták]

Boot-time race condition sounds plausibly:

* It could explain not having this issue on my old laptop (SSD+HDD mix – Debian's root.img stored on SSD, volatile.img stored on HDD) and having the issue on the new one (SSD only), despite having almost the same config. (But I've performed a clean install, so I can't exclude other influences.)
* The VM it works with has somewhat larger /rw/config/rc.local. It performs various tasks (installing some VM-specific software, adding a new trusted CA, enabling and starting few services etc.), none of them is directly related to environment variables. So, maybe either some load or delay in rc.local causes the race condition to be won.

Regards,
Vít Šesták 'v6ak'

[Unman]

It does sound plausible. But how is it that a vanilla template on SSD
doesnt show the problem? If this were the case I would have thought there would be
many reports.

If you put a long delay in to rc.local in one of the problematic qubes
does that solve the problem?

[Chris Laprise]

Based on my own attempts to get Qubes-VM-hardening working as a service
in Debian 8, I'd say the startup chain in Debian 8 is rather fragile.
Debian 9 has been more stable and its what I've been using for 98% of my
computing needs for the past year.

[Chris Laprise]

On 06/07/2017 05:23 PM, Vít Šesták wrote:

BTW, have you tried enabling 'jessie-testing' and updating to see if
that helps?

[Vít Šesták]

I've traced the issue a bit. Maybe the race condition is not true. The VM updates works in has root's shell configured to bash instead of zsh. But that's still strange:

* user with bash: OK
* user with zsh: OK
* root with bash: OK
* root with zsh: environment issues

I've also tried updating to Jessie-Backports (this is probably what you meaned by testing) in a cloned template and it did not change. I am also upgrading to Stretch (in another clone).

[Chris Laprise]

On 06/08/2017 05:54 AM, Vít Šesták wrote:
> I've traced the issue a bit. Maybe the race condition is not true. The VM updates works in has root's shell configured to bash instead of zsh. But that's still strange:
>
> * user with bash: OK
> * user with zsh: OK
> * root with bash: OK
> * root with zsh: environment issues

Hmmm, I haven't used zsh in like... 20 years.

>
> I've also tried updating to Jessie-Backports (this is probably what you meaned by testing) in a cloned template and it did not change. I am also upgrading to Stretch (in another clone).

I did mean jessie-testing in /etc/apt/sources-list.d/qubes-r3.list.
Sometimes updating the Qubes packages can help with issues like this.

[Unman]

There are known issues with using other shells. (I'd mistakenly stated
that zsh was fine, without checking this use case.) I had done some
work on this which I should dust off.
Upgrading the templates wont fix this problem.

unman