Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

From: "Jason Crawford" <[email-masked]>
Date: Fri, 24 Aug 2001 13:30:26 -0400

Just so it doesn't get overlooked....  do we agree with what Geoff has said
below?

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

"Clemm, Geoff" <[email-masked]>@w3.org on 08/21/2001 12:18:30 AM

Sent by:  [email-masked]

To:   Webdav WG <[email-masked]>
cc:
Subject:  RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

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

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Monday, August 20, 2001 11:57 PM
To: Webdav WG
Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

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?

Thanks,

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: Greg Stein <[email-masked]>
Date: Sun, 26 Aug 2001 18:02:16 -0700

It is fine with me, as long as a server can refuse the UNLOCK even if it
does not implement the ACL specification.

Cheers,
-g

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

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 27 Aug 2001 12:08:04 -0700

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

No.

> introduces ways to constrain who can do an operation.  So we're

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.

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