Hello Michal,
Michal Privoznik [2016-11-04 8:47 +0100]:
> That means that whenever a VM is being started up, libvirtd (our
> daemon we have) relabels all the necessary paths that QEMU process
> (representing VM) can touch.
Does that mean it's shipping an udev rule that does that? Or actually
listens to uevents by itself (possibly via libudev) and applies the
labels?
> However, I'm facing an issue that I don't know how to fix. In some cases
> QEMU can close & reopen a block device. However, closing a block device
> triggers an event and hence if there is a rule that sets a security
> label on a device the QEMU process is unable to reopen the device again.
Is that triggering the above libvirtd action (in the daemon via
libudev or via an udev rule), or is that something else?
> My question is, whet we can do to prevent udev from mangling with our
> security labels that we've set on the devices?
Sorry for my ignorance, but my question in return is: What's the udev
rule that mangles with it in the first place? I don't see any such
rule in upstream systemd or in Debian/Ubuntu, but it's of course
possible that Fedora ships such a rule via another package.
> One of the ideas our lead developer had was for libvirt to set some kind
> of udev label on devices managed by libvirt (when setting up security
> labels) and then whenever udev sees such labelled device it won't touch
> it at all (this could be achieved by a rule perhaps?). Later, when
> domain is shutting down libvirt removes that label. But I don't think
> setting an arbitrary label on devices is supported, is it?
It actually is -- they are called "tags" (TAG+=) and "properties"
(ENV{PROPNAME}="foo"), see udev(7). So indeed the most straightforward
way would be to tag or set a property on those devices which you want
to handle in libvirtd yourself, and then add something like
TAG=="libvirtd", GOTO="skip_selinux_context"
[... original rule that changes context goes here ..]
LABEL="skip_selinux_context"
But for further details I need to understand the actual rules
involved.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list