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