RE: ACL and lockdiscovery

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