On 27.10.2016 04:07, Bjoern Walk wrote: > Michal Privoznik <mprivozn@xxxxxxxxxx> [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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list