Subject: Re: DAV:read privilege and browsing

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 30 Nov 2006 22:07:58 -0800

Right.  This is how, for example, a typical UNIX file system works.

	-wsv

On Nov 30, 2006, at 8:57 AM, Julian Reschke wrote:

> Basically, if the server exposes the names of children that the user  
> doesn't have access to, security works in a different way. For  
> instance, users will have to move resources they don't want to be  
> visible into a specific folder, and deny read access to that folder  
> as well.

---

From: "Kevin Wiggen" <[email-masked]>
Date: Thu, 30 Nov 2006 08:08:54 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Thursday, November 30, 2006 12:32 AM
To: Wilfredo Sánchez Vega
Cc: WebDav WG; [email-masked]'
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