- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Mon, 27 Aug 2001 12:08:04 -0700
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
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