Re: [PATCH for v5.3.0 10/17] security: Remember owner only for top level image

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/10/19 11:35 PM, Cole Robinson wrote:
On 3/28/19 11:04 AM, Michal Privoznik wrote:
Here is the problem: If all disks had XATTRs (i.e. domains using
them were started with owner remembering turned on) then
refcounting implemented in XATTRs would work nicely and we could
set the whole backing chain and restore it later. But world is
not that simple. As soon as there is one domain that was started
with the feature turned off (or simply by older libvirt), the
XATTR refounting does not reflect the actual number of uses by
running domains and therefore any attempt to restore might cut
off the old domain.

There is no simple way around this. Except artificially turning
the feature off for the rest of the backing chain.


Is there a thread discussing the issues that led to disabling this code?
I looked but couldn't find one. I could use some more context on what
case this patch fixes, and the upcoming patches. I'm having trouble
groking these comments

I don't think I discussed it on the list. But imagine there are two domains: vm1 and vm2. Let them have one disk each like this:

vm1: disk1.qcow2 (RW) -> base.qcow2 (RO)
vm2: disk2.qcow2 (RW) -> base.qcow2 (RO)

(I never know which way to draw the arrows, but I'm sure you get the idea. base.qcow2 is shared between the domains)

Now, start only vm1. This means that both disk1.qcow2 and base.qcow2 are relabelled. And imagine that seclabel remembering is on. The paths then have some XATTRs on them where original owner is stored. So far so good.

But then the vm2 is started with seclabel remembering turned off (e.g. it's on a different host and base.qcow2 is on shared NFS, or simply sysadmin turned the feature off and restarted libvirtd).

Okay, we have two domains running, base.qcow2's refcount would be 1 (as read from XATTRs) even though it's used by two domains. But leave that aside for a moment.

Now, vm1 is shut down. The label restore is started. Because the domain had the feature on when starting it up (it remembers that in the status XML), the whole backing chain would be restored (btw turning the feature off affects only freshly started domains). So we start with disk1.qcow2. It's refcount is 1 and therefore the original owner is restored. Then we proceed to base.qcow2. It's refcount is again 1 (as read from XATTRs) and thus we restore its original owner. But this is problematic, becuase that operation possibly cuts off vm2's access.

Well, if the refcounter of base.qcow2 would reflect the actual number of times the file is in use then we'd have no problem - restore wouldn't be done there, merely just refcounter update. But the refcounter only shows how many times the file is in use by domains with the feature enabled.

Hopefully, this makes it clearer.

I can't think of a clever way around this. Any other than remembering only the top layer and leaving the rest of the backing chain alone. This feels like solving a cluster problem to me.

Michal

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux