[libvirt] Regarding libvirt patchset "Keep original security label"

[Michal Privoznik]

[Adding libvirt-list as others might chime in or when somebody is
solving similar issue they can find answers in the archive.]

On 02/19/2018 10:09 AM, Toni Peltonen wrote:
> Hi,
> 
> Sorry to bother you with ages old stuff like this (https://www.redhat.com/archives/libvir-list/2014-September/msg00551.html) patch set.
> 
> I did some proof of concept work on my laptop during the weekend with a couple of CentOS 7 virtual machines running shared GFS2 mount (with working dlm locking) and libvirtd + QEMU guests on top of that. I am running the latest libvirtd packages from CentOS upstream.
> 
> While I managed to get dlm and global POSIX locking working as expected when I added virtlockd to the picture to actually hold locks for the VM images I ended up getting some gray hair realizing that this ages old security label issue is still present. The situation is basically still the same:
> 
> - On a shared filesystem (like GFS2), despite virtlockd locks working as expected, libvirtd still (as expected with current code) tries to change the ownership and security labels of the target file (QCOW2 image)
> 
> - This sudden change causes the virtual machine running on the other host to drop as read-only since SELinux starts preventing all write operations for it
> 
> - With SELinux in Permissive mode on the host that runs the virtual machine everything work as expected

So you have a disk that is shared between two domains? One way to avoid
the problem is to have <shareable/> in disk definition so that libvirt
doesn't restore disk labels. However, that still might not work for you
because it means that libvirt still changes labels on domain start.

So far the only way to prevent this from happening is using custom
labels https://libvirt.org/formatdomain.html#elementsDisks .

> 
> 
> I saw that the only code available (that I could easily find and understand) to really tackle this issue was your patch set from as early as 2014. It seems it never hit upstream though, at least I can't find any of the relevant parts in the upstream code.
> 
> I am just reaching out to ask whether this patch set was left out intentionally (https://www.redhat.com/archives/libvir-list/2014-September/msg00551.html), just lost in time or if you are aware of any other work that might be in progress to tackle this issue in the upstream?

Unfortunately, the patches were abandoned and the issue is even worse. I
remember having a discussion on this topic lately (although can't recall
where). Turns out, we firstly relabel the disks and only after that we
try to obtain disk locks. So if the latter fails (e.g. because another
domain holds the locks) the lables are changed anyway. The suggested
solution was to have two locks: one for disk contents the other for disk
metadata (like security labels).

Anyway, I don't think there's anybody working on this actively. Sorry.

Michal