Re: [libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains
On Wed, Mar 06, 2019 at 04:05:13PM +0000, Daniel P. Berrangé wrote:
On Wed, Mar 06, 2019 at 03:41:16PM +0100, Erik Skultety wrote:
> So, according to this report [1], Mesa enabled on-disk cache for its shaders
> which it tries to create either under XDG_CACHE_HOME/mesa_shader_cache or under
> HOME/.cache/mesa_shader_cache. Since libvirt doesn't set XDGs and HOME is only
> passed iff the QEMU process isn't run with SUID, Mesa will default to the home
> directory specified in /etc/passwd.
> Because of this, Mesa will fail to create the cache and QEMU refuses to start
> the VM (interestingly enough, Intel reports the problem too, but Mesa disables
> the cache and the VM starts). This series proposes usage of XDG variables to
> fix the problem by pointing XDG variables to hypervisor specific directory
> under libvirt's libDir. Additionally, HOME is also enforced for all VM
> processes and points to the base hypervisor libDir directory.
> To illustrate this further:
>
> system qemu:
> HOME=/var/lib/libvirt/qemu/domain-5-f-live \
> XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.local/share \
> XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.cache \
> XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-f-live/.config \
>
> session qemu:
> HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live \
> XDG_DATA_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.local/share
\
> XDG_CACHE_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.cache \
> XDG_CONFIG_HOME=/home/eskultet/.config/libvirt/qemu/lib/domain-4-f-live/.config \
For the bug report IIUC we should only need to set XDG_CACHE_HOME
as that's the one which needs to be writable and which SELinux quite
rightly denies. It is also safe to redefine this because cache data
is liable to be purged at any time, so apps must expect to see an
empty cache directory.
Yes, XDG_CACHE_HOME is the only one needed to fix the BZ.
I'm very wary about setting HOME or XDG_DATA_HOME or XDG_CONFIG_HOME
as I think that is pretty likely to break valid usage.
For example, when QEMU is configured to use pulseaudio as its audio
backend, I believe this will want to read config files in normal
$HOME and/or $XDG_{CONFIG|DATA}_HOME.
I'm glad you mentioned pulseaudio, it's a good example, because pulseaudio
should never run as root, instead, it will run in context of the 'qemu' user,
right? This is all fine in session mode, but in system mode, having set none of
the above apart from cache, pulseaudio might try to read from '/' as that's
QEMU's home dir. Any reasonable app should default to reading configs and data
from /etc or /usr/local if there's nothing found in HOME or XDG location. But
when it comes to writing, having apps write anything to root's home doesn't
seem like a good idea to me, so I believe that at least for system mode, we
want to override all of the variables.
I'd also be okay with not redefining the variables for session mode, but the
following motivated me to do so:
1) consistency, if we do it in 1 mode, why not the other (although
personally, I don't like enforcing session mode that much)
2) isolation, configs are fine, but any data an app wants to write, I'm
really not sure how they handle multiple instances, so I approached this
like non-shared filesystems, any 2 apps need to have their own view of
the location and I also don't want them to even think of trying to write
something to root's home
Similary if using the GTK frontend these dirs are needed to load
the toolkit preferences such as theme.
You mean for <graphics>? If so, we don't support GTK.
I expect there are other relevant config files that would be
affected too.
>From a security POV these files should not be a problem since they
would all be read-only from QEMU's POV.
Erik