Feature Request - Qubes R3.x - custom default_user value should not break qubes integration (gui, pulse audio)

[yilmi]

Qubes OS version :

R3.x

Affected TemplateVMs :

found on fedora-23 and debian-8 but could be reproduced on any template using qubes-gui-agent-linux

---

Expected behavior:

When setting a custom default_user value for a TemplateVM / AppVM Qubes, pulse audio sink is working properly

Actual behavior:

If we use a custom default_user value for a TemplateVM / AppVM, pulse audio sink is broken

Steps to reproduce the behavior:

From dom0 :
qvm-prefs -s yourvmname default_user yourcustomusername

From yourvmname :
Run any app using pulseaudio, it should not work

General notes:

Qubes GUI agent service is executing /usr/bin/qubes-gui which itself is executing qubes-run-xorg.sh.

qubes-run-xorg.sh prepare qubes configuration args for Xorg and start it :

exec su -l user -c "/usr/bin/xinit $XSESSION -- $XORG :0 -nolisten tcp vt07 -wr -config xorg-qubes.conf > ~/.xsession-errors 2>&1"

The problem is that X is always started as default qubes vm user, (ie. user). Pulseaudio is also running as the user appearing in qubes-run-xorg.sh because it is started through xdg autostart

I didn't spent a lot of time on this topic but I suppose that qubes-gui could read default_user from somewhere and pass it as an arg to qubes-run-xorg.sh

---

Related issues:

[marmarek]

Changing default user in standard templates was never supported (it's only for HVM, and especially Windows), so the bug here is: "changing default_user property is not blocked".
There is much more places than this one where "user" value is hardcoded.
Feature request for supporting different user is very unlikely to be implemented (at least by core team).

[marmarek]

Changing default user in standard templates was never supported (it's only for HVM, and especially Windows), so the bug here is: "changing default_user property is not blocked".
There is much more places than this one where "user" value is hardcoded.
Feature request for supporting different user is very unlikely to be implemented (at least by core team).

[yilmi]

Changed the description to "Feature request"

[yilmi]

Changed the description to "Feature request"

[yilmi]

Hi @marmarek,

I would like to fix the issue reported on the qubes-run-xorg.sh script. I understand this is not the only place where we have a hardcoded username but would to start with this.
I was thinking about using the xenstore to push the default_user value so it can be accessed from the VM. Then retrieve to pass it as an argument to the -l switch of the su in the qubes-run-xorg.sh
Would you be ok with this approach?

[yilmi]

Hi @marmarek,

I would like to fix the issue reported on the qubes-run-xorg.sh script. I understand this is not the only place where we have a hardcoded username but would to start with this.
I was thinking about using the xenstore to push the default_user value so it can be accessed from the VM. Then retrieve to pass it as an argument to the -l switch of the su in the qubes-run-xorg.sh
Would you be ok with this approach?

[marmarek]

First of all, use QubesDB instead of xenstore (to ease migration to other hypervisors). It's very similar, simply use qubesdb-* tools instead of xenstore-*.
Do you think the same template could be used with different user names in different VMs? If not, maybe it should be rather configuration inside the VM, later communicated to dom0, instead requiring configuration in both places always - you always need to configure template side, at least to create that custom user.

[marmarek]

First of all, use QubesDB instead of xenstore (to ease migration to other hypervisors). It's very similar, simply use qubesdb-* tools instead of xenstore-*.
Do you think the same template could be used with different user names in different VMs? If not, maybe it should be rather configuration inside the VM, later communicated to dom0, instead requiring configuration in both places always - you always need to configure template side, at least to create that custom user.

[yilmi]

Thanks for the feedback, I will use qubesdb-* instead.

At the moment, one template VM can't have 2 AppVMs with different usernames. The default_user is ignored when I try to set it directly on the AppVM. The value can only be changed through the TemplateVM and will affect AppVMs based on it.

I'll try to prepare a fix that you can review with more detail.

[yilmi]

Thanks for the feedback, I will use qubesdb-* instead.

At the moment, one template VM can't have 2 AppVMs with different usernames. The default_user is ignored when I try to set it directly on the AppVM. The value can only be changed through the TemplateVM and will affect AppVMs based on it.

I'll try to prepare a fix that you can review with more detail.

[marmarek]

It's done.

[marmarek]

It's done.