RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

Jason Crawford writes:
> Just so it doesn't get overlooked....  do we agree with what
> Geoff has said below?

No.

Geoff Clemm writes:
> Well, that's a really easy change, i.e. all you have to do is
> absolutely nothing (:-).  Currently, section 11 in 2518 places
> no constraints on who can do an UNLOCK operation (i.e. if you
> can discover the lock token, you can request an UNLOCK).  The ACL spec
> introduces ways to constrain who can do an operation.  So we're
> done (:-).

This interpretation is very much counter to the intent of RFC 2518.  Section
7.1 states, "A write lock MUST prevent a principal without the lock from
successfully executing a ... UNLOCK ... on the locked resource."

Now, you could certainly argue that "having a lock" implies merely "having
the lock token", but this is counter to the definition of a lock token as an
identifier of a lock (not the lock itself), and the last paragraph of 6.3:
"Having a lock token provides no special access rights. Anyone can find out
anyone else's lock token be performing lock discovery. Locks MUST be
enforced based on whatever authentication mechanism is used by the server,
not based on the secrecy of the token values."

The intent of the first sentence of the last paragraph of 7.6 is that it is
the COMBINATION of the LOCK TOKEN *AND* valid AUTHENTICATION CREDENTIALS
that grants access to a locked resource. ("In order to prevent these
collisions a lock token MUST be submitted by an authorized principal in the
If header for all locked resources that a method may interact with or the
method MUST fail.") Since 7.1 clearly lists UNLOCK as a method affected by
LOCK, then UNLOCK is affected by this requirement in 7.6.

> > It sounds like we might have consensus opinion that the power to unlock
> > someone else's locked resource should be under ACL control.
> > Could someone that feels strongly about this propose a wording and
placement
> > in 2518 that makes this proposal concrete?

Now, we may want to *change* the semantics of RFC 2518 to allow people other
than the lock holder to perform an unlock, as controlled by an access
control entry. However, in my mind this is clearly a change, and not an
interpretation.

As well, it seems to me that what people really want is a "SIEZE" or "TAKE"
operation, where the resource remains locked, but ownership of the lock is
transferred (with a new lock token generated). If you grab a lock using
UNLOCK, it's possible that someone else could sneak in during the epsilon of
time the resource is unlocked.

- Jim

Received on Monday, 27 August 2001 15:11:14 UTC