W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: PROPFIND behaviour regarding collections with non-listable me mbers

From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Fri, 12 Oct 2001 15:56:45 -0700
Message-Id: <p0510031fb7ed224ecc8c@[]>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Clemm, Geoff" <gclemm@rational.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
At 9:03 PM +0200 10/12/01, Julian Reschke wrote:
>that's something we could do, but that would hide the difference between a
>collection that's empty and a collection where you don't have "list"
>permission to.

When security is so tight that people aren't allowed to even know 
about the existence or non-existence of members, these cases (a 
collection that's empty versus one that contains members "invisible 
to you") aren't supposed to be distinguishable.  To see this, 
consider the case where a collection has some visible and some 
invisible members (from a particular user's point of view): just the 
visible members should be listed.

But I think there's an entirely different spec issue here: whether or 
not DAV collections can hide the existence of members at all. 
Section 8.1 on PROPFIND says:

    Consequently, the multistatus XML element for a collection resource
    with member URIs MUST include a response XML element for each member
    URI of the collection, to whatever depth was requested. Each response
    XML element MUST contain an href XML element that gives the URI of
    the resource on which the properties in the prop XML element are

This seems to require you either:

a. to list the members and then say 403 for any properties, or

b. to return 403 for any PROPFIND with depth > 0 on the containing collection.

Note that neither of these options meets the security requirements of 
"a user must not be able to determine whether or not a collection has 
a given member," but I don't think that 2518 intended to make it 
illegal for servers to enforce this kind of security.  So I think 
there is a spec issue here.


>  I'm not sure this is a good idea.
>>  -----Original Message-----
>>  From: w3c-dist-auth-request@w3.org
>>  [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
>>  Sent: Friday, October 12, 2001 8:54 PM
>>  To: Webdav WG
>>  Subject: RE: PROPFIND behaviour regarding collections with non-listable
>>  me mbers
>>  Depends on what you mean by "has the right to list the collection
>>  but not its members".  If the client does not have the right to even
>>  see the names of the members, then the collection should just look
>>  empty, since the client should not be able to even know it has
>>  members.  If the client has the right to see the name of members
>>  but not to see the properties of members, then listing their names
>>  with the Forbidden status seems reasonable to me.
>>  Cheers,
>>  Geoff
>>  -----Original Message-----
>>  From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>  Sent: Friday, October 12, 2001 7:33 AM
>>  To: Webdav WG
>>  Subject: PROPFIND behaviour regarding collections with non-listable
>>  members
>>  I think we have identified something that needs to be clarified
>>  in RFC2518:
>>  Given a collection X, where the principal does have rights to list the
>>  collection itself, but not it's members.
>>  Currently our server will distinguish between depth 0 and 1, that is a
>>  PROPFIND with depth 0 will report the collection (and it's properties) OK,
>>  while a PROPFIND with depth 1 will result in something like:
>>  <response>
>>	<href>X</href>
>>	<status>HTTP/1.1 403 Forbidden</status>
>>  </response>
>>  This is because once a response element for X is available,
>>  there's no other
>>  way to distinguish between the case where the collection actually
>>  is empty,
>>  or the collection is non-empty, but the principal doesn't have
>>  the right to
>>  list it's members.
>>  Feedback appreciated.
>>  Julian

Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Friday, 12 October 2001 18:58:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:24 UTC