RE: locks and trust (Re: Rejected Requirements)

What you have just described is equivalent to a bunch of authors appending to the same document ONLY or only ever adding resources to a collection. Adding a mail message to a mailbox is different from updating an existing mail message.

Here is a slightly different description of the same principle.

There are permissions which regulate access to resources.
Some users have read only permissions and some may add resources or overwrite them.
Those who may add or overwrite resources essentially (as a group) hold a shared write lock on the resource.
By adding or removing people from this group (in the broadest sense of the word) one can change the membership of the shared lock.
Some users have the permission to place an exclusive lock on the resource.
Only they may then overwrite this resource
Only they may remove the exclusive lock (admin users excepted)

Same conclusion as before.

Cheers
Dylan

----------
From:  Gregory J. Woodhouse[SMTP:gjw@wnetc.com]
Sent:  Montag, 2. Juni 1997 09:38
To:  Dylan Barrell
Cc:  'Jim Whitehead'; w3c-dist-auth@w3.org
Subject:  RE: locks and trust (Re: Rejected Requirements)

On Mon, 2 Jun 1997, Dylan Barrell wrote:

> I would like to see the shared-lock be an optional portion of the WebDAV
> standard. I think the minimum requirement for locking is exclusive
> locking and this should be the minimum that WebDAV requires. 
> 
> Our experience with Livelink has been that exclusive locks are good
> enough. All other access can be regulated by the permissions. I.e. a
> shared lock can be seen as the permission of a group of people to write
> to the resource. Add to this the ability to change the permissions and
> the ability for someone to lock the resource (another individually
> specifiable permission) and you have all the flexibility you need. 
> 
> In conclusion I don't even see the need for shared locks.
> 
> Cheers
> Dylan 
> 

I have a feeling we're talking past eachother here. In fact, I'm not at
all sure who I agree with and who I disagree with because I'm not clear on
who is using what terminology. It seems to me that locks can vary along
at least four orthogonal axes:

mandatory/advisory
exclusive/shared
read/write/both
privilege

To go back to the mail example, I sort my mail into multiple inboxes using
procmail and then access them with an IMAP client. Quite frequently, I see
mail arrive in a mailbox while I have it open. From my point of view, I
hear a beep and the display is updated. Internally, procmail locks my
mailbox just long enough to deliver the message and then releases the
lock. This is an example of a mandatory exclusive lock. Once the message
is delivered, I can continue with my work undisturbed. Now, let's suppose
I  start up a second instance of Pine. What will happen is that the second
process is already in use and warn me. In  addition, both instances of
Pine will be accessing the mailbox in read-only mode. In other wors the
first process had an exclusive advisory read/write lock that was
effectively revoked by the second process, replacing it with a shared
readonly lock. Now, mail can still continue to arrive, and will be allowed
to secure temporary exclusive locks while delivering mail without
disturbing th existing advisory lock. Another possible scenario is where I
telnet in, start up Pine, disconnect, and then telnet back in again. What
happens here is that I am warned that Pine is attempting to secdure a lock
on a mailbox which is already locked by process <whatever>. In this case,
that process is no longer active, so my process can succesfully revoke the
orphaned lock. This raises an interesting point: though these locks are
"advisory" (and technically they all are unless the MDA is configured to
use flock() to lock the mailbox), it is not up to the user (or user
process) to decide when to modify or revoke a lock. In essence, these
locks are only in that they can be revoked or modified by a process with
sufficient privilege (by mail subsystem itself). (Note that I'm not
talking about privilege in the UNIX sense of the term.)


---
Gregory Woodhouse
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.

Received on Monday, 2 June 1997 11:24:20 UTC