On Thu, Mar 07, 2019 at 10:37:14AM +0000, Daniel P. Berrangé wrote:
> 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 :-)
Alright, thanks for comments, I'll respin with the changes we talked about.
Erik
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
