Re: [libvirt] [PATCH 0/3] Define XDG variables for hypervisor domains

On Thu, Mar 07, 2019 at 09:27:29AM +0100, Erik Skultety wrote: > 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. Yes, ok, for system mode setting all of them is sensible for the reasons you say. > 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) To me one of key reasons for session mode (aside from access to disk images in $HOME) is that it allows VMs to integrate with services / apps in that users session, such as PA. So isolating them is going to eliminate that key feture of session mode & break valid usage IMHO. > 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 We don't really expect QEMU (or things it links to) to write to these dirs, but if they did try SELinux would block it. IMHO if you wanted stricter isolation then QEMU needs to be running a different UID. > > 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. Yes for graphics. Lack of GTK support is a bug :-)