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

[Michal Privoznik]

On 27.10.2016 04:07, 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.

As Dan says, that's a separate issue. But if we have this helper in, we
might turn it later into a small service that would remember seclabels
(and refcount them). There was a patch set earlier to implement just
this but for some reason it was abandoned. But I don't want to say this
out loud and scare possible reviewers O:-)

Michal