Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

From: "Jason Crawford" <[email-masked]>
Date: Wed, 5 Sep 2001 10:54:26 -0400

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,   [email-masked]

---

From: Daniel Brotsky <[email-masked]>
Date: Wed, 5 Sep 2001 08:59:04 -0700

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

-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 5 Sep 2001 16:49:04 -0700

> question for the spec is: *how* do they allow this?

I'd assumed this would be the same way any user does an UNLOCK.  I don't
think there's any need to define a new syntax (more on this later in the
email).  Xythos WFS supports UNLOCK by the resource owner as well as by the
lock creator.  The resource owner must do PROPFIND "DAV:lockdiscovery" first
to find out what the lock token is, then remove it.

> *how* is it under access control?

Not everything that is allowed by WebDAV has its own privilege in DAV ACLs.
Note particularly that the ability to LOCK the file isn't covered by its own
privilege!  A server might implement the privilege to blow away another's
lock as part of the write-acl privilege.  Of course, the ACL framework is
flexible enough to allow servers to define sub-privileges.

Eg 1: custom:lock, custom:delete and custom:write might be separate custom
privileges that are covered under the framework of the DAV:write privilege.

Eg 2: custom:unlock and custom:set-privilege might be custom privileges that
are covered under the framework of the DAV:write-acl privilege.

WFS has implemented unlock-by-non-lock-owners to be allowed only by the
owner of the resource.  I don't think this needs to be part of the ACL spec
right now.  An extension to the ACL spec might be useful, once ACL is done.

> that choose one policy or the other?

Yes. Xythos WFS requires the ability for a resource owner to remove a lock
that was created by some other user.  This must be accessible over WebDAV
because resource owners don't have administrative access to the system.  The
primary reason this is a requirement is because resource owners have limited
quotas.  If they can't blow away a lock created by some other user, then
they can't delete the resource and free up space when they reach their
quota.

Even on systems without quotas, the goal of minimizing administrative costs
requires this feature.  It's too costly for users to be phoning the support
staff every time they need a lock removed for some "urgent" reason.

> were just unlocking their own.

Clients should NEVER EVER do this, regardless of whether the server supports
this UNLOCK-by-non-lock-owner.  That would mean that the client is relying
on access control of the server to regulate whether or not it may blow away
the lock.  That fails in the simple case when the user has two software
applications that both support DAV!  If I'm using Windows Word with Web
Folders to open and lock a file, then I start up Acrobat to see if I can
view the same file I'm editing, it would be wrong for Acrobat to grab the
lock and allow edits.  That kind of unpredictability is unacceptable.

> (Especially because the spec provides
> no way to reliably determine who owns a lock.)

This is a good point -- and this is already a failing of WebDAV, with or
without UNLOCK_BY_NON_LOCK_OWNER.  Clients that crash or miss the response
from the server need to make sure that the lock is theirs before grabbing
the lock token using PROPFIND.  Can lockowner be used for this purpose?

This should be a separate RFC2518 issue.  How about
"HOW_TO_IDENTIFY_LOCK_OWNER".

> So I believe we need

If we solve the problem of telling what client created the lock, which I've
pointed out we ought to solve anyway, we wouldn't have to add syntax to the
UNLOCK call.

> that get opened by allowing explicit unlocking,

I hope I've answered a few of those questions, although I agree a new
RFC2518 issue must be raised (HOW_TO_IDENTIFY_LOCK_OWNER).  If we solve that
question, I don't see any further open issues that would prevent
UNLOCK_BY_NON_LOCK_OWNER.

Lisa

---

From: Greg Stein <[email-masked]>
Date: Thu, 13 Sep 2001 18:34:59 -0700

I don't think it is right to allow somebody other than the lock owner to
unlock the thing, but the position below does give me room to refuse to do
so. Thus, I am comfortable with that position.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/