Subject: ACL and lockdiscovery

From: Horst Liermann <[email-masked]>
Date: Wed, 17 Sep 2003 19:08:07 +0200

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

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 17 Sep 2003 11:16:33 -0700

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: [email-masked] [mailto:[email-masked]]
> On Behalf Of Horst Liermann
> Sent: Wednesday, September 17, 2003 10:08 AM
> To: [email-masked]'
> 
> 
> Hi all,
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 17 Sep 2003 16:49:20 -0700

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Sedlar
> Sent: Wednesday, September 17, 2003 11:17 AM
> To: 'Horst Liermann'; [email-masked]
> 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
> 
> > 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
> 
> 
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 18 Sep 2003 08:17:00 -0400

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

[email-masked] wrote on 09/17/2003 07:49:20 PM:

> > > [mailto:[email-masked]]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 18 Sep 2003 09:32:20 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Geoffrey M Clemm
Sent: Thursday, September 18, 2003 5:17 AM
To: [email-masked]
Subject: RE: ACL and lockdiscovery

Cheers, 
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Sep 2003 09:50:30 -0400

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

[email-masked] 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 
> On Behalf Of Geoffrey M Clemm
> Sent: Friday, September 19, 2003 3:19 PM
> To: [email-masked]

> 
> 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" <[email-masked]> wrote on 09/18/2003 12:32:20 PM:
> 
> > Unfortunately, withholding the locktoken from the client that 
> > requested that lock 

> > On Behalf Of Geoffrey M Clemm

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 19 Sep 2003 18:10:36 +0200

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

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Geoffrey M Clemm
  Sent: Friday, September 19, 2003 3:51 PM
  To: [email-masked]
  Subject: RE: ACL and lockdiscovery

  Cheers,
  Geoff

whole
(i.e.preventing
other),

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 19 Sep 2003 15:26:50 +0200

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

  -----Original Message-----

  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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Sep 2003 09:18:39 -0400

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Sep 2003 12:43:15 -0400

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?

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),

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 19 Sep 2003 19:11:53 +0200

Indeed.

I wasn't aware about the optionality of the lock token. Another interesting
client test case :-)

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Geoffrey M Clemm
  Sent: Friday, September 19, 2003 6:43 PM
  To: [email-masked]
  Subject: RE: ACL and lockdiscovery

  Cheers,
  Geoff

already?

whole

---

From: "Guido Casper" <[email-masked]>
Date: Sun, 21 Sep 2003 11:52:24 +0200

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 <[email-masked]> wrote:
> whole point of having lock tokens instead of just a server-side lock
> (i.e. preventing
>> 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
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 22 Sep 2003 11:30:28 -0400

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 22 Sep 2003 09:40:27 -0700

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

> > 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
> > 
> > 
> > > 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),
> > >> 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.
> > >> 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
> > >>
> > >>>> 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
> > >>>>

---

From: "Guido Casper" <[email-masked]>
Date: Mon, 22 Sep 2003 20:15:32 +0200

OK, thanks for clarification to Geoff and Lisa.

Guido

Geoffrey M Clemm <[email-masked]> wrote:
>> 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
>>
>>
>>> server-side lock (i.e. preventing

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 24 Sep 2003 11:45:16 +0200

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

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, September 22, 2003 6:40 PM
> To: 'Geoffrey M Clemm'; [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 24 Sep 2003 09:31:50 -0700

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

> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Wednesday, September 24, 2003 2:45 AM
> To: Lisa Dusseault; 'Geoffrey M Clemm'; [email-masked]
> 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
> 
> --
> 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.
> >
> > > > 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).
> > > >
> > > > > 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
> > > > >> messages & cause support calls. Thus, as a matter of 
> > > > >> interoperability, a server would at
> > > least have
> > > > >> That is not correct.  RFC-2518 explicitly states in section 
> > > > >> 13.8 (where the DAV:lockdiscovery property is defined):
> > > > >>
> > > > >> to UNLOCK the resource, a server could very 
> reasonably choose 
> > > > >> to hide the lock-token information.
> > > > >>
> > > > >>> I'd also point out that the lockdiscovery property MUST 
> > > > >>> contain all the lock tokens, regardless of access control
> > > settings.  This

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 24 Sep 2003 18:58:10 +0200

> Sent: Wednesday, September 24, 2003 6:32 PM
> To: 'Julian Reschke'; 'Geoffrey M Clemm'; [email-masked]
other
> What if we ditched the DTD entirely and simply use English?

I'd prefer to keep them and continue to use them the same way as currently
done in RFC2518, RFC3253 and the various drafts closing completion.

All that's needed is the following general clarification:

"This document uses XML DTD fragments as a purely notational convention.
WebDAV request and response bodies can not be validated due to the specific
extensibility rules defined in section 23 of [RFC2518] and due to the fact
that all XML elements defined by this specification use the XML namespace
name "DAV:". In particular:

- element names use the "DAV:" namespace,
- element ordering is irrelevant,
- extension elements (elements not already defined as valid child elements)
may be added anywhere, except when explicitly stated otherwise,
- extension attributes (attributes not already defined as valid for this
element) may be added anywhere, except when explicitly stated otherwise."

(see
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-10.htm
l#rfc.section.1>).

This reduces changes to existing and currently last-called documents to a
minimum, clarifies (hopefully all) issue and keeps the readability of DTDs.

> Something like

If this is the main issue, clarifying that an "ANY" content model indicates
that the element is *not* extensible (contrary to the default case) may
suffice (note that this would apply to the content of the DAV:prop element
in PROPFIND marshalling).

Julian