- From: Daniel Brotsky <dbrotsky@adobe.com>
- Date: Wed, 5 Sep 2001 08:59:04 -0700
- To: Webdav WG <w3c-dist-auth@w3c.org>
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