RE: ACL and lockdiscovery

BTW:

the current discussion is a very good example why the new DTD usage in
RFC2518bis is IMHO a bad idea -- it doesn't state anymore which child
elements are mandatory.

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 Lisa Dusseault
> Sent: Monday, September 22, 2003 6:40 PM
> To: 'Geoffrey M Clemm'; w3c-dist-auth@w3.org
> Subject: RE: ACL and lockdiscovery
>
>
>
> >
> > For the question of why a lock token is ever sent back to the
> > client, (I assume you mean "in lock discovery" ... it of
> > course has to be sent back to the client creating the lock).
> > The reason is that there can be several locks on a resource,
> > and the client may only want to UNLOCK a particular lock.
>
> Yes, this is important, and I'll add a bit more detail for client
> considerations:
>
> 1. The client MUST remember the lock token and/or put some
>    self-identifying information in the owner field of the lock
>    That's because if I'm running two WebDAV clients, possibly
>    either on the same computer or two different computers but
>    both logged in as me, those two clients need to use only their
>    own locks.  It would mess things up if my synchronization client
>    used the lock token taken out by my authoring client and
>    overwrote all my new changes.  It's not enough to be the user
>    that owns the lock, the client must also be the same client (or
>    coordinating with the same client) that took out the lock.
>
> 2. If the server doesn't provide the lock token in the lock discovery
>    property value, how are client supposed to know *which* locks
>    are currently on the resource?   The lock token is currently the
>    only way to identify a lock.  This information can help the client
>    figure out what's going on -- e.g. to be confident that the lock
>    that the client requested an hour ago is still valid.
>
> Lisa
>
> >
> > Cheers,
> > Geoff
> >
> > Guido wrote on 09/21/2003 05:52:24 AM:
> >
> > > I dare to disagree.
> > > The lock token ALLOWS clients to be written for the behaviour Geoff
> > > describes (2 clients working on behalf of the same user
> > cannot unlock
> > > each others lock).
> > >
> > > But does that imply that clients acommodating the use case
> > of wanting
> > > to unlock another client's lock are not compliant? Why
> > would the lock
> > > token then be sent back to the client ever (instead of just
> > a general
> > > locking state)?
> > >
> > > Guido
> > >
> > >
> > > Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> wrote:
> > > > 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 Wednesday, 24 September 2003 05:45:21 UTC