RE: ACL and lockdiscovery

A compliant client should be prepared for the absence of a lock token,
since the DTD for DAV:activelock explicitly marks it as being optional.

But that of course doesn't answer Julian's actual question, which is
whether existing clients are correctly implemented (:-).

Cheers,
Geoff

Julian wrote on 09/19/2003 12:10:36 PM:

> OK,
> 
> so what's the best interoperable way to hide the lock token? Simply 
> leaving out the locktoken/href element, or supplying a dummy (such 
> as "DAV:private") instead? Does any currently deployed server do this 
already?
> 
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Geoffrey M Clemm
> Sent: Friday, September 19, 2003 3:51 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: ACL and lockdiscovery

> 
> Just to be clear, I was in no way advocating that the presence 
> of the lock itself should be hidden.  I was just indicating the 
> cases when the suppression of the *lock-token* field in the 
> lock-discovery data is likely to be desireable. 
> 
> Cheers, 
> Geoff 
> 
> w3c-dist-auth-request@w3.org wrote on 09/19/2003 09:26:50 AM:
> 
> > I basically agree with Geoff. 
> > 
> > However there's the legitamite use case that a UI needs to get the 
> > active locks just in order to be able to display whether a resource 
> > is locked or not. So maybe we should think of a way that handles 
> > this case, without having to reveal "too much". 
> > 
> > Julian 
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org 
[mailto:w3c-dist-auth-request@w3.org]
> > On Behalf Of Geoffrey M Clemm
> > Sent: Friday, September 19, 2003 3:19 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: ACL and lockdiscovery
> 
> > 
> > If the client doesn't have permission to do an UNLOCK, 
> > or if the lock automatically times out 
> > (the two use cases identified where the server is likely to withhold 
> > the lock token), the client either cannot do an UNLOCK, or does not 
> > need to do an UNLOCK. 
> > 
> > WRT clients that do not store the lock tokens, but rather try to steal 

> > any lock token that is allowed by access control, this violates the 
whole 
> > point of having lock tokens instead of just a server-side lock (i.
> e.preventing
> > two clients working on behalf of the same user from stomping on 
> each other), 
> > and such a client should be fixed, not catered to by servers. 
> > 
> > Cheers, 
> > Geoff 
> > 
> > "Lisa Dusseault" <lisa@xythos.com> wrote on 09/18/2003 12:32:20 PM:
> > 
> > > Unfortunately, withholding the locktoken from the client that 
> > > requested that lock 
> > > would break UNLOCK for some clients that don't store their own 
> lock tokens.
> > > Those clients might show error messages & cause support calls. 
> > > Thus, as a matter of interoperability, a server would at least have 
to 
> > > be careful in providing incomplete information in lockdiscovery. 
> > > 
> > > This area is murkier than I had thought.  Should there be a 
> clarification in
> > > RFC2518bis? It would obviously be easier to write interoperable 
clients 
> > > if all servers had to behave the same in this area.  Is there a de 
facto 
> > > minimum standard here that we can clarify in the next rev? 
> > > 
> > > lisa 
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org 
[mailto:w3c-dist-auth-request@w3.org] 
> > > On Behalf Of Geoffrey M Clemm
> > > Sent: Thursday, September 18, 2003 5:17 AM
> > > To: w3c-dist-auth@w3.org
> > > Subject: RE: ACL and lockdiscovery
> > 
> > > 
> > > That is not correct.  RFC-2518 explicitly states in 
> > > section 13.8 (where the DAV:lockdiscovery property is defined): 
> > > 
> > > "The server is free to withhold any or all of this information 
> > > if the requesting principal does not have sufficient access rights 
> > > to see the requested data." 
> > > 
> > > In particular, if the client does not have sufficient access 
> > > rights to UNLOCK the resource, a server could very reasonably 
> > > choose to hide the lock-token information. 
> > > 
> > > In addition, a server for which locks have a reasonably 
> > > short maximum expiration may chose to never expose the lock tokens 
> > > (i.e. nobody has sufficient access rights to see the lock tokens). 
> > > 
> > > Cheers, 
> > > Geoff 
> > > 
> > > w3c-dist-auth-request@w3.org wrote on 09/17/2003 07:49:20 PM:
> > > 
> > > > 
> > > > I'd also point out that the lockdiscovery property MUST contain
> > > > all the lock tokens, regardless of access control settings.  This
> > > > is not considered a security leak, because authorization is also
> > > > needed to use a lock token.  So this is the server logic to apply
> > > > whenever the client provides a lock token: 
> > > > 
> > > > Is this the same authorization context that took out the lock? 
> > > >   Yes {
> > > >    Allow the operation normally, provided the operation is 
> > > >    allowed, and provided the lock token is correct and all
> > > >    required lock tokens are provided, etc.
> > > >   } No {
> > > >    Is this an UNLOCK operation, with an authorization that
> > > >    includes permission to delete others' locks?
> > > >    Yes {
> > > >       perform UNLOCK
> > > >    } No {
> > > >       Fail request
> > > >    }
> > > >   }
> > > > 
> > > > Lisa
> > > > 
> > > > > -----Original Message-----
> > > > > From: w3c-dist-auth-request@w3.org 
> > > > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Eric Sedlar
> > > > > Sent: Wednesday, September 17, 2003 11:17 AM
> > > > > To: 'Horst Liermann'; w3c-dist-auth@w3.org
> > > > > Subject: RE: ACL and lockdiscovery
> > > > > 
> > > > > 
> > > > > 
> > > > > The ACL spec hasn't defined a privilege specifically to 
> > > > > control read access to the lockdiscovery property, or even a 
> > > > > privilege to control access to all the privileges in total. 
> > > > > An individual server implementation could provide such a 
> > > > > privilege and aggregate it under <dav:read>, but this isn't 
required.
> > > > > 
> > > > > --Eric
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: w3c-dist-auth-request@w3.org 
> > > > > > [mailto:w3c-dist-auth-request@w3.org]
> > > > > > On Behalf Of Horst Liermann
> > > > > > Sent: Wednesday, September 17, 2003 10:08 AM
> > > > > > To: 'w3c-dist-auth@w3.org'
> > > > > > 
> > > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > some questions about lockdiscovery and ACL's
> > > > > > 
> > > > > > Suppose, you have a server with WebDAV ( including lock) and 
it 
> > > > > > support's ACL. What is the behavior for lockdiscovery, can 
> > > > > I see all 
> > > > > > lock token or am I only allowed to see the tokens where I 
> > > > > am the owner 
> > > > > > of the lock ? As far as I understand, lockdiscovery reports 
> > > > > all locks. 
> > > > > > Is this a security leak ?
> > > > > > 
> > > > > > Best Regards
> > > > > >    Horst
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > >