Subject: Re: PROPFIND Depth:1 and ACLs

From: Werner Donné <[email-masked]>
Date: Mon, 14 May 2007 21:59:11 +0200

Hi,

Section 8.2 of RFC 2518bis has two paragraphs which say:

"If there is an error retrieving a property then a proper error
  result MUST be included in the response.  A request to retrieve the
  value of a property which does not exist is an error and MUST be
  noted, if the response uses a multistatus XML element, with a
  response XML element which contains a 404 (Not Found) status value.

  Consequently, the multistatus XML element for a collection resource
  with member URLs MUST include a response XML element for each member
  URL of the collection, to whatever depth was requested. Each
  response XML element MUST contain an href XML element that gives the
  URL of the resource on which the properties in the prop XML element
  are defined.  URLs for collections appearing in the results MUST end
  in a slash character.  Results for a PROPFIND on a collection
  resource with internal member URLs are returned as a flat list whose
  order of entries is not significant."

This mandates a response element for resource B.

It further also says:

"Properties may be subject to access control. In the case of allprop
  and propname, if a principal does not have the right to know whether
  a particular property exists then the property should be silently
  excluded from the response."

This still doesn't allow for omitting a response element. At most a
property can be left out.

My conclusion is that when you have the read privilege on a collection,
you have the right to see its entire contents, i.e. all of its members.
There is no notion of a partial read privilege.

The problem, however, is that there is no method to retrieve the
contents of a collection. You have to use PROPFIND with which you
can't request for an empty set of properties. You have to ask for
something, which means you always request the collection contents
together with information about its members. In the case the principal
doesn't have the read privilege for some member, a 403 status code should
be placed in its response element. According to the content model
of the "response" element it can be done with a "status" element
directly under "response", so no property names have to be exposed.
It anyway doesn't make sense to set the status for each property,
because RFC 3744 doesn't allow to set privileges on individual
properties.

Note that having to use PROPFIND to retrieve the contents of a
collection has a serious impact on performance when ACLs are supported.

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 May 2007 23:06:57 +0200

> Section 8.2 of RFC 2518bis has two paragraphs which say:

9.1.

> property can be left out.

I think you're reading the spec correctly, but I'm going to say this is 
not what the intention was, and certainly is not what many servers 
implement. It seems to me that this needs to be corrected.

> There is no notion of a partial read privilege.

Personally I agree this the more sound approach, but I'm pretty sure 
many implementors disagree and just hide the entries. I think we need to 
allow that.

> together with information about its members. In the case the principal

That's correct; and I think we should have relaxed that. An empty <prop> 
element should be allowed; clients could easily test for that by just 
trying it and analyzing the result; it's it's 207, the server understood 
the request..

> be placed in its response element. According to the content model

That's what the SAP KM WebDAV server is doing.

> collection has a serious impact on performance when ACLs are supported.

Could you a be a bit more specific? Would a PROPFIND where just the 
member names are being returned sufficient?

Best regards, Julian

(adding to new issues to 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>)

---

From: Werner Donné <[email-masked]>
Date: Tue, 15 May 2007 09:17:12 +0200

> member names are being returned sufficient?

Indeed, because as soon as one property is also returned an ACL check is
required for each member, which is expensive if the collection has a lot
of members, say a few thousand.

I agree it should be allowed to hide collection members if this fits
some security policy better. If I would speak as a user, however, I
probably would hide a document in a collection that is not readable. It
feels closer to real life.

> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>) 

Best regards,

Werner.

---

From: "Tim Olsen" <[email-masked]>
Date: Tue, 15 May 2007 08:31:15 -0400

> of members, say a few thousand.

If you're using a SQL database, you can optimize this with a proper
SQL query.  Just JOIN all the children of a collection against the acl
check you normally do.

-Tim

---

From: Werner Donné <[email-masked]>
Date: Tue, 15 May 2007 14:44:13 +0200

That is true. You have to join with the ACEs granting or
denying the "read", "read-acl", "read-current-user-privilege-set"
and "all" privileges. The result set should then be matched
with the current user. This can't be part of the same join,
because of group memberships.

Note that the original result set you fetch from the database,
i.e. without ACEs, should be multiplied by the average number
of occurrences of the above-mentioned privileges per ACL. This
will depend on how well the user organises principals in groups.

Werner.

---

From: "Tim Olsen" <[email-masked]>
Date: Tue, 15 May 2007 09:00:45 -0400

> because of group memberships.

They can be part of the same join if you keep a separate table of the
transitive closure of group memberships.

-Tim

---

From: Werner Donné <[email-masked]>
Date: Tue, 15 May 2007 15:13:28 +0200

You are right. That would be much more efficient for
any ACL check.

Werner.