[libvirt] [RFC] secdrivers remembering original labels

[Michal Prívozník]

On 08/06/2018 10:30 AM, Daniel P. Berrangé wrote:

>>
>> So do we really need virtlockd for this? I mean, the whole purpose of it
>> is to hold locks so that libvirtd can restart independently, without
>> losing the lock attached. However, since the metadata lock will be held
>> only for a fraction of a second and will be not held through more than a
>> single API aren't we just fine with libvirtd holding the lock? The way I
>> imagine this to work is the following:
> 
> There were two reasons for virtlockd. The first was the persistent holding
> of locks, but the other reasons is that POSIX fcntl() locks are horrific.
> If one thread has an FD open with a lock held, if another thread opens and
> closes the same underlying file, the first thread's lock will get dropped.
> 
> We can't be confident that other threads won't open the file, so the only
> way to be safe was to put locking in to a separate process where we know
> exactly what all threads are doing.

Ah. That's terrible. But IIUC avoidable by using OFDs instead (which are
not available on BSD I presume).

> 
> 
>> Frankly, I've started implementing this with virtlockd already, but the
>> changes I made so far simply do not feel right, e.g. I have to change
>> lock_protocol.x so that virLockSpaceProtocolAcquireResourceArgs has this
>> 'type' argument which tells virtlockd which byte we want to lock.
> 
> We could perhaps make use of the "flags" field, giving a flg to identify
> the lockspace to use. This could be turned into an offset server side.

Okay, I'll try this. Thanks!

Michal