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

[Michal Privoznik]

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.

Michal