W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 23] lock discovery vs shared locks

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 29 Oct 2005 08:32:23 -0400
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF1FD337AB.8AE61795-ON852570A9.00444B22-852570A9.0044E47F@us.ibm.com>
The likelihood of damage from lock stealing can be decreased by
only allowing a given user/principal to steal his own locks, but
(as indicated in my original message below :-) it does not prevent
two clients of a given user/principal from overwriting each others
changes.  Since there is a completely safe way of handling this
scenario (i.e., streaming an UNLOCK/LOCK sequence to the server),
I maintain my position that a client should never "steal"
a lock by discovering the lock-token via PROPFIND, even if that
lock was held by another client of that same user, and therefore
lock tokens should never be exposed in a PROPFIND.


Geoff wrote on 10/29/2005 04:43:39 AM:
> Geoffrey M Clemm wrote:
> > 
> > The last sentence is incorrect.  A lock token appears in a PROPFIND
> > lockdiscovery only if the server wishes to expose it.  I have argued
> > in the past that a sensible server should never expose a lock token in 
> > PROPFIND lockdiscovery, since it just allows a client of a user
> > to incorrectly re-use a lock token still in use by another client
> > of that user.  So if we say anything, it should "A server SHOULD NOT
> > include a lock token in a PROPFIND lockdiscovery, since it introduces
> > the possibility of two clients of a given user overwriting each others
> > changes".
> Here I'll disagree with Geoff :-)
> "lock stealing" is further controlled (or can be controlled) by checking 

> the principal as well.
> I *do* agree that it makes sense to have one coherent section that gives 

> advice on how not to reveal lock tokens. For instance, servers are 
> allowed to report the locks, but not to disclose the lock tokens (see 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.12.1>).
> Best regards, Julian
Received on Saturday, 29 October 2005 12:32:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC