RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

Sorry not to weigh in sooner; I've been underwater.

1. While I agree with what Jason sent as a "position statement," it 
feels like it misses the issues that a protocol spec needs to address:

a. Of course servers may allow principals other than a lock owner to 
unlock a resource: servers can do whatever they want with locks.  The 
question for the spec is: *how* do they allow this?

b. Of course if a server allows principals to do something, and the 
server supports access control, then the allowance should be under 
access control: it's only logical.  The question for the spec is: 
*how* is it under access control?

c. Of course there are tradeoffs around any authorization policy. 
The question for the spec is: are there any *requirements* on servers 
that choose one policy or the other?

2. As to a: I believe that using the exact same syntax for UNLOCK 
regardless of whether you own the lock (or just have permission to 
blow locks away) would be very error-prone.  It would mean that 
clients that routinely do lock discovery (rather than remembering 
tokens) could easily blow away others' locks when they thought they 
were just unlocking their own.  (Especially because the spec provides 
no way to reliably determine who owns a lock.)  So I believe we need 
some mechanism for saying, in an UNLOCK call, that I expect the lock 
to be owned by someone else and I want to unlock it anyway.  (And 
this form would fail if I owned the lock.)

3. As to b: Does the ACL spec talk specifically about a "remove 
someone else's lock" permission?  Are there constraints about whether 
or not this is tied to having the permission to lock the resource? 
Or write it?  Also, we have experimented with servers that, while 
they don't allow one user to unlock another's lock via DAV (because 
we interpreted the spec as forbidding that), will in fact honor a 
LOCK request from one (adminstrative) user by simply blowing another 
user's lock away.  This not only is an entirely different mechanism 
for unlocking, it raises a host of ACL-related questions.

4. As to c: Are we going to require servers that allow unlocking to 
grant long timeouts?  Are we going to require that servers which 
allow unlocks grant "implicit" unlocks (as described in the last 
paragraph)?  I suspect not, but I don't think the spec is really the 
place for speculation about tradeoffs.  We would need to rewrite any 
such talk to be design rationale for allowing unlocking by others.

As you can see, I think we're a ways from an operable concensus 
around this issue.  I think there are a raft of important questions 
that get opened by allowing explicit unlocking, and I'm not at all 
sure we have enough experience to actually move the spec this way at 
this point.  It might be way better to simply confirm that servers 
MUST refuse a standard-form UNLOCK call from a non lock-owner (just 
as they MUST refuse a PUT by a non lock-owner).  Servers that then 
wish to allow administrative unlocking could still do so via 
proprietary extensions (a non-standard form of UNLOCK, for example), 
but the spec wouldn't be in the position of trying to legislate 
administrative procedures that we don't yet have agreement about.

     dan

At 10:54 AM -0400 9/5/01, Jason Crawford wrote:
>Hey WebDAV'ers,
>    A couple of the disagreeing parties (JimW, GeoffC, LisaD) put there
>heads together to come up with a compromise on the issue of allowing
>non-lock owners to UNLOCK a resouce.  The compromise is that the following
>items should be said in the spec.
>
>- A server MAY allow principals other than a lock owner to unlock a
>resource
>-  If a server supports the unlocking of a resource by someone other than
>the lock owner, this capability SHOULD be under access control.
>- There is a tradeoff in allowing non-owners of a lock to unlock a
>resource.  It can be beneficial to allow non-lock owners to perform UNLOCK
>requests because it allows the adminstrator of the server to configure the
>server to grant longer lock timeouts because the administrator knows that
>there is a process in place to allow users to deal with forgotten locks
>left by other users.  On the other hand, a disadvantage of unlocking
>someone else's lock is that can create a situation where two users are
>working on modifications to the same resource at the same time which can
>result in a client having to perform an merge that wasn't previously
>planned.
>
>If we have a consensus around this, the wording that we will use will be
>very close to this.   If you have any comments on the position or wording,
>please speak up.
>
>J.
>
>------------------------------------------
>Phone: 914-784-7569,   ccjason@us.ibm.com

-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Wednesday, 5 September 2001 11:59:53 UTC