RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

> 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?

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.

> 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?

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.

> 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?

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.

> 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.

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
> 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.)

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.

> 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,

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

Received on Wednesday, 5 September 2001 19:49:26 UTC