Re: ACL and lockdiscovery

OK, thanks for clarification to Geoff and Lisa.

Guido

Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> wrote:
> 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 14:13:47 UTC