lock-breaking ui

[John A Meinel]

Robert Collins wrote:
> On Mon, 2006-02-20 at 09:07 -0600, John A Meinel wrote:
>> If possible, but I don't know how much it will actually help them.
>>
>> I will say that lock holders need to know that they have lost the
>> lock,
>> rather than unlocking someone else's lock.
>>
>> I don't know how we do this. Do we just keep an open file descriptor
>> to
>> the directory, and rename that descriptor? All other methods seem to
>> have a race condition. (I check that lock/details is correct, but then
>> when I go to rename, it has actually been modified).
> 
> 'open file descriptor' is not something we can do except locally.
> 
>> I think the unlocking race condition is potentially very dangerous. I
>> don't want a bogus client who was sitting on a lock to unlock me,
>> after
>> I've broken their control.
> 
> so the race is:
> client A locks
> client A starts to unlock and verifies it has the lock
> client B breaks
> client B locks
> client A unlocks
> 
>> Would we have to use hard-links for this? Something like:
>>
>> lock-base/
>>   pending/
>>   released/
> 
> I don't think hard links are needed.
> 
>> Create a temp directory in pending, and a temp file, hard-link the
>> temp
>> file to pending/details, rename pending/tempdir/ to locked/ and rename
>> pending/temp-file to released/temp-file (or leave it in pending).
>>
>> Then when you go to rename, you could check the hard-link count on
>> your
>> temp-file, but you still have the race condition between checking the
>> count, and actually renaming lock/ to released/temp-dir/
> 
> I think the crux of the matter is there is no 'read and release' atomic
> operation : and you can't build one without having a locking system
> already or an atomic operation provided for you.
> 
> However, we do have an atomic 'release' operation, and we can tell by
> inspection *after* the unlock that we unlocked the wrong thing:
> 
> client A locks
> client A starts to unlock and verifies it has the lock
> client B breaks
> client B locks
> client A unlocks
> client A reads the unlocked lock and finds it does not have its expected
> nonce in the metadata.
> client A restores the lock to where it was and raises a lock error.
> 
> This makes it visible to someone at least. 
> 
> Now, note that any number of 'client B verifies' that we add after
> client B locks are useless: the race condition depends on client A
> breaking the lock after client B runs in an breaks and locks under it,
> and thats an arbitrarily long time.
> 
> I'm not sure that there is a solution here. Arch certainly did not have
> one.
> 
> Rob

Well, Arch's solution was that the directory was removed underneath it,
so that it didn't have anything to unlock. (And any changes would be
made to a directory that would disappear).

But yes, the best I can come up with is that A would restore the lock.
Of course we add a further race condition where it restores it, and B
has already gone away. But at least the Branch is incorrectly locked
rather than incorrectly unlocked.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060220/1b2a8706/attachment.pgp