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]
