lock-breaking ui

[Robert Collins]

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


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/20570dc6/attachment.pgp