Traversal allowance (on unix filesystem) has nothing to do with read allowance.
your can provide everyone with traversal allowance on 
/home/tchize/ with such permission:
rwx--x--x 

(that is user has read/write/execute permission on dir and others have only 
execute)
execute allows traversal but no listing of content.

Moreover it's not a good idea to compare ACL with a filesystem. Most unix 
filesystem 
don't use an inheritance mechanism, which make their management very different 
to DAV ACL


Le Mardi 28 Juin 2005 18:29, Warwick Burrows a écrit :
> 
> I don't think this is a bug. Requiring at least read on the parents makes a 
> lot of sense. If you consider that a user could not have arrived at the point 
> in the tree at which they want to write unless they have read permission to 
> its parents all the way down the uri path. This is much like the access 
> control on a filesystem which is the same. You can't write into a directory 
> or modify a file in the directory unless you can traverse to it first.
> 
> Warwick
> 
> 
> > -----Original Message-----
> > From: Thomas Bellembois [mailto:[EMAIL PROTECTED] 
> > Sent: Tuesday, June 28, 2005 11:14 AM
> > To: Slide Developers Mailing List
> > Subject: Re: ACL evaluation - conclusion - bug?.
> > 
> > 
> > Hello,
> > 
> > Yes, I could reproduce the bug (with two differents servers). But I 
> > would like to know if somebody else can reproduce it and if 
> > it is really 
> > a bug.
> > There could be a reason for Slide developers to process the write 
> > requests like that...
> > If it is a bug what are the classes to patch ?
> > I am very eager to have answers to this question because we 
> > are about to 
> > use Slide on a large scale with sharing functionalities. :-)
> > 
> > Thomas
> > 
> > delbd wrote:
> > 
> > >accroding to RFC 3744  WebDAV Access Control Protocol  May 
> > 2004 3.1.  
> > >DAV:read Privilege
> > >
> > >   The read privilege controls methods that return 
> > information about the
> > >   state of the resource, including the resource's 
> > properties.  Affected
> > >   methods include GET and PROPFIND.  Any implementation-defined
> > >   privilege that also controls access to GET and PROPFIND must be
> > >   aggregated under DAV:read - if an ACL grants access to 
> > DAV:read, the
> > >   client may expect that no other privilege needs to be 
> > granted to have
> > >   access to GET and PROPFIND.  Additionally, the read privilege MUST
> > >   control the OPTIONS method.
> > >3.2.  DAV:write Privilege
> > >
> > >   The write privilege controls methods that lock a resource 
> > or modify
> > >   the content, dead properties, or (in the case of a collection)
> > >   membership of the resource, such as PUT and PROPPATCH.  Note that
> > >   state modification is also controlled via locking (see 
> > section 5.3 of
> > >   [RFC2518]), so effective write access requires that both write
> > >   privileges and write locking requirements are satisfied.  Any
> > >   implementation-defined privilege that also controls 
> > access to methods
> > >   modifying content, dead properties or collection 
> > membership must be
> > >   aggregated under DAV:write, e.g., if an ACL grants access to
> > >   DAV:write, the client may expect that no other privilege 
> > needs to be
> > >   granted to have access to PUT and PROPPATCH.
> > >
> > >Appendix B. WebDAV Method Privilege Table (Normative)
> > >...
> > >   
> > +---------------------------------+---------------------------------+
> > >   | METHOD                          | PRIVILEGES            
> >           |
> > >   
> > +---------------------------------+---------------------------------+
> > >   | PUT (target exists)             | <D:write-content> on 
> > target     |
> > >   |                                 | resource              
> >           |
> > >   | PUT (no target exists)          | <D:bind> on parent 
> > collection   |
> > >   |                                 | of target             
> >           |
> > >
> > >read priviledge on path should not be needed, and it seems you can 
> > >reproduce bug
> > >(as i said i didn't have much time to check it here, i siply 
> > granted read privilege, heritable on
> > >source and everything went well). Maybe filling a bug report 
> > should be a good idea :D
> > >
> > >
> > >Le Mardi 28 Juin 2005 16:08, Thomas Bellembois a écrit :
> > >  
> > >
> > >>Hello,
> > >>
> > >>ACL evaluation is in accordance with your explanations.
> > >>But for the "write" permission Slide apparently requires a "read"
> > >>permission on the full path of the resource for the 
> > connected user, as 
> > >>David said (we can see that in debug mode).
> > >>I have not found this requirement in the RFC, but perhaps 
> > not read well...
> > >>
> > >>Regards,
> > >>
> > >>Thomas
> > >>
> > >>    
> > >>
> > >
> > >  
> > >
> > 
> > 
> > -- 
> > +---=(    Thomas Bellembois    )=---+
> > | CRI - University of Rennes 1 - FR | 
> > [EMAIL PROTECTED] 
> > | |
> > | +33 2 23 23 69 60                 |
> > +-----------------------------------+
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
Is there life after /sbin/halt -p?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to