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

[Daniel P. Berrangé]

On Thu, Jun 20, 2019 at 02:32:40PM +0200, Michal Privoznik wrote:
> 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.

Yep, no objection to that.

> > 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|