RE: DAV:read privilege and browsing

FYI -- Xythos would consider it a security hole if a webdav client can do a directory listing and view files names that people do NOT have read access to.  I hate when my boss has that file called FIRE-KEVIN.doc in his directory.

This is NOT how other servers view this (for instance SAP), but I would believe it is up to the server how "secure" they want to be.  Yes they can find out if they try to WRITE to a file location that has a pre-named file, however there might be other reasons the user cannot write to that location.

Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
Sent: Thursday, November 30, 2006 12:32 AM
To: Wilfredo Sánchez Vega
Cc: WebDav WG; 'acl@webdav.org'
Subject: Re: DAV:read privilege and browsing


Wilfredo Sánchez Vega schrieb:
>   I'm looking for a bit of guidance as to the DAV:read privilege and its 
> effect on PROPFIND.
> 
>   If I don't have DAV:read on a resource, but I do have DAV:read on its 
> parent collection, when I do a PROPFIND with depth=1 on the parent, 
> should I be able to see the child?

I guess the answer is "it depends". In the SAP KM implementation, we 
return all children, but if the user doesn't have read access, they come 
back with a 403 status. As far as I can tell, this is exactly to the 
letter of the spec, and has the advantage that a client can see the 
difference between "not there" and "not accessible". This may be 
importance for instance when creating new items in the collection - you 
don't want to hide something only to tell the user later that it can't 
be created because it already exists.

>   It's not clear to me from the ACL spec what I can or can not expose 
> without DAV:read.  My interpretation is that DAV:read on the parent 
> means you can read its list of children.

Yep. The issue here is that RFC3744 only talks about PROPFIND in 
general, without making a statement about Depth=1. Maybe we need to fix 
this.

>   I obviously shouldn't be able to read (all of?) the child's 
> properties, but there is some merit to wanting to be able to see that 
> the child's URI is present, even if I can't read the child's properties 

Right.

> or content.  I might even want to expose the DAV:resource-type property 
> so you can tell if it's a collection, etc.

I don't think RFC3744 would allow the latter, even though I would 
consider it harmless...

>   This also nominally affects GET, when I'm rendering a directory 
> listing of the parent.  I'd like to show all children, but if you aren't 
> allowed to see them in PROPFIND, it makes sense that they should be 
> hidden from the rendered listing as well.

Correct. I personally think they should appear in both, potentially 
marked up as non-accessible (greyed out...).

> ...

Funny enough, over on the Slide mailing list we are just discussing 
this. Seems that the Slide client easily gets confused, but hopefully 
that can e fixed.

Best regards, Julian

Received on Saturday, 2 December 2006 01:50:38 UTC