RE: ACL and lockdiscovery

Yeah, it is a quandary.  On the one hand, if we include a DTD with elements
listed, implementors tend to barf when extra elements are sent.  On the
other
hand, if we don't list the required elements, implementors tend not to send 
them.  

What if we ditched the DTD entirely and simply use English?  Something like
this:

  'lockdiscovery' property (in 'DAV:' namespace):
	MUST contain one 'activelock' elements for each lock on the resource
	MUST be empty if no locks exist on the resource

  'activelock' element (in 'DAV:' namespace):
	MUST contain one 'locktype' element
	MUST contain one 'lockscope' element
	MUST contain one 'depth' element 
	MAY contain one 'owner' element (MUST contain the value provided by
the client if one was provided)
		(MUST NOT contain more than one 'owner' element)
	MAY contain one 'timeout' element
		if omitted, timeout value MUST be infinite
	MUST contain one 'locktoken' element 
	MAY contain additional elements which can be ignored 


This would tend to drive us, the spec writers, to include more information,
more
guidance, rather than less.  That's because the DTDs don't provide an easy
place to say whether an element may be extended with new elements, or under
what conditions an element is required.

Lisa




> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> Sent: Wednesday, September 24, 2003 2:45 AM
> To: Lisa Dusseault; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org
> Subject: 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 12:32:59 UTC