Re: [libvirt] [PATCH v4 18/25] security: Don't remember owner for shared resources

On 6/20/19 1:58 PM, Daniel P. Berrangé wrote: > On Thu, Jun 20, 2019 at 12:23:07PM +0200, Michal Privoznik wrote: > > On 6/17/19 3:29 PM, Daniel P. Berrangé wrote: > > > On Thu, Apr 25, 2019 at 10:19:54AM +0200, Michal Privoznik wrote: > > > > This effectively reverts d7420430ce6 and adds new code. > > > > > > > > Here is the problem: Imagine a file X that is to be shared > > > > between two domains as a disk. Let the first domain (vm1) have > > > > seclabel remembering turned on and the other (vm2) has it turned > > > > off. Assume that both domains will run under the same user, but > > > > the original owner of X is different (i.e. trying to access X > > > > without relabelling leads to EPERM). > > > > > > How do we get into this situation ? Is this the case when we > > > have a guest which was running before libvirt was upgraded, and > > > then a new guest is launched ? > > > > Yes, that's one of the possible scenarios. Another possible scenario would > > be (and this won't happen yet in reality beacuse NFS still does not > > implement XATTRs, but once they do we might hit it): two daemons and one > > shared NFS mount. One of the daemons has the feature enabled, the other has > > it disabled. But as I say, this won't happen with NFS today. But maybe there > > are some other shared filesystems which do implement XATTRs? > > IMHO if you are using a set of virt hosts with a shared NFS and have only > enabled label mgmt on a subset of hosts that's a deployment error in > general. > > Having said that, this is precisely the scearnio you'd have if you are > part way through a libvirt upgrade across many hosts. > > Our core problem is that we have zero knowledge about other hosts, neither > their config, or even whether they exist at all, so we can't do the safe > thing automatically. Yep, this is the root cause of the problem. > > I'm still not a fan of just giving up & deleting the feature though. > > How about we create a qemu.conf option to turn on/off label mgmt for > shared volumes, defaulting to off. Document that it should only be > turned off if all hosts are participating & no historical VMs are > running ? This could work. But if possible, I'd probably do that in a follow up series? I mean, this series is long enough already and I can see it working/being merged as I write what you suggest.

> In theory on upgrade, we could look at all running VMs on our own host > and record the ref count data that is otherwise missing. That could at > least let it work correctly on a the single-host non-shared FS scenario. Yeah, since we don't know about other daemons we could do that only for local files.