Re: ACL and lockdiscovery

I should have been clearer.  By "steal a lock token", I meant
"do an update operation with a lock token that was issued to
another client", not "unlock a lock issued to another client".

Any appropriately authorized client can UNLOCK a locked resource.
There is no problem with that (and it doesn't matter whether or
not it is a client running on behalf of the same user that took
out the lock).

The problem is when a client performs an update by using a lock
token issued to another client (where it discovered
the lock token using lock discovery).  That is the behavior that
violates the whole point of having a lock token.

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.

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 Monday, 22 September 2003 11:30:20 UTC