[libvirt] [PATCH 00/17] Avoid races with udev

[Daniel P. Berrange]

On Thu, Oct 27, 2016 at 01:07:57PM +0200, Bjoern Walk wrote:
> Michal Privoznik <mprivozn at redhat.com> [2016-10-26, 02:52PM +0200]:
> > I've came across interesting bug recently. The problem was that
> > user tried to start a domain, but qemu was denied access to some
> > device. Even though we relabelled it initially. By debugging I
> > found the root cause: while we were starting qemu, udev came and
> > restored original security labels. Sigh. We have two options
> > here:
> > 
> > a) write out series of udev rules so that whenever it tries to
> > relabel something our rule will stop it from doing so
> > 
> > b) write a small helper binary that will udev call in order to:
> >  1) detect whether device is in use by libvirt
> >  2) get seclabel that was set by libvirt
> > 
> > These patches implement the latter approach. While these patches
> > make life easier for us, there is still a race when udev might
> > restore the device's seclabel before we had chance to flush
> > internal database of seclabels for the helper binary. This is
> > something I'm currently focusing on. But before I get there, here
> > are patches that makes the problem much more bearable.
> > 
> > In case you want to try these patches, here are some scratch builds:
> > 
> >  https://mprivozn.fedorapeople.org/udev/
> > 
> > Also, you can find them on my branch:
> > 
> >  https://github.com/zippy2/libvirt/commits/udev_labels2
> > 
> > 
> > This beast is turned off by default, to turn it on you'll need to add:
> > 
> >  write_udev=1
> > 
> > to qemu.conf.
> > 
> 
> Hello Michal,
> 
> will this work (or can be made working) for file-based disk images as
> well? Currently, the user can provoke a race condition when defining two
> domains using the same file-based disk image and not (wrongly)
> specifying the <shareable/> element. What happens is that when the while
> the first domain is running, the second domain start will relabel disk
> image for its own usage, essentially cutting of the first running
> domain. This caused a crash of the first QEMU process until
> https://patchwork.ozlabs.org/patch/658163/, now the first domain still
> reports I/O errors.

That is a separate issue - that requires libvirt to be tracking the
labelling it is doing. There was a series that could fix this, which
was related to restore of originall labelling on guest shutdown.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|