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