W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: ACL and lockdiscovery

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 19 Sep 2003 19:11:53 +0200
To: "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEHDIIAA.julian.reschke@gmx.de>
Indeed.

I wasn't aware about the optionality of the lock token. Another interesting
client test case :-)

--
<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 6:43 PM
  To: w3c-dist-auth@w3.org
  Subject: 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
  > > > > >
  > > > > >
  > > > > >
  > > > >
  > > > >
Received on Friday, 19 September 2003 13:12:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT