[libvirt] [PATCH v2] qemu: Introduce caching whether /dev/kvm is accessible

[Daniel P. Berrangé]

On Tue, Oct 30, 2018 at 04:47:32PM +0100, Michal Privoznik wrote:
> On 10/30/2018 04:07 PM, Daniel P. Berrangé wrote:
> > On Tue, Oct 30, 2018 at 03:45:36PM +0100, Michal Privoznik wrote:
> >> On 10/30/2018 02:46 PM, Michal Privoznik wrote:
> >>> On 10/30/2018 01:55 PM, Daniel P. Berrangé wrote:
> >>>> On Tue, Oct 30, 2018 at 10:32:08AM +0000, Daniel P. Berrangé wrote:
> >>>>> On Tue, Oct 30, 2018 at 11:08:45AM +0100, Michal Privoznik wrote:
> >>>>>> On 10/30/2018 10:35 AM, Daniel P. Berrangé wrote:
> >>>>>>> On Tue, Oct 30, 2018 at 09:13:50AM +0100, Michal Privoznik wrote:
> >>>>>>>> On 10/29/2018 06:34 PM, Marc Hartmayer wrote:
> >>>>>>>>> Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU
> >>>>>>>>> group. This reduces the overhead of the QEMU capabilities cache
> >>>>>>>>> lookup. Before this patch there were many fork() calls used for
> >>>>>>>>> checking whether /dev/kvm is accessible. Now we store the result
> >>>>>>>>> whether /dev/kvm is accessible or not and we only need to re-run the
> >>>>>>>>> virFileAccessibleAs check if the ctime of /dev/kvm has changed.
> >>>>>>>>>
> >>>>>>>>> Suggested-by: Daniel P. Berrangé <berrange at redhat.com>
> >>>>>>>>> Signed-off-by: Marc Hartmayer <mhartmay at linux.ibm.com>
> >>>>>>>>> ---
> >>>>>>>>>  src/qemu/qemu_capabilities.c | 54 ++++++++++++++++++++++++++++++++++--
> >>>>>>>>>  1 file changed, 52 insertions(+), 2 deletions(-)
> >>>>>>>>>
> 
> 
> > Not really. Udev is in use everywhere, so this behaviour makes the
> > patch useless in practice, even though it is technically right in
> > theory :-(
> > 
> 
> Well, caching owner + seclabels + ACLs won't help either. What if user
> loads some profile into AppArmor or something that denies previously
> allowed access to /dev/kvm (or vice versa)? What I am saying is that
> there are some security models which base their decisions on something
> else than file attributes.

The virFileAccessibleAs check for /dev/kvm was put in their to ensure
that we correctly report usability of KVM in the capabilities XML
according to file permissions/ownership. Essentially KVM is not usable
until the udev rule is applied to change permissions to world accessible
or to set the kvm group.

I don't think we need to care aout selinux/apparmor restrictions - just
need to be no worse than what we cope with today, which is just perms
and owner/group.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|