I see. But this behavior does not look to be compliant with the WebDAV
ACP RFC.
Moreover we could allow a user to access a directory without being able
to browse the full path.
ex : /files/homedir/toto/share
Toto wants to share the directory 'share' with a user 'titi'. Titi can
access this directory using a Web folder pointing directly to the path
"/files/homedir/toto/share".
This could be done with the following permissions :
/files grant read all inheritable
/files/homedir/toto grant all toto inheritable - grant read titi - deny
all all inheritable
/files/homedir/toto/share grant read (write) titi inheritable
But titi could also read files in the toto directory...
What we would like to do is :
/files
/files/homedir/toto grant all toto inheritable - deny all all inheritable
/files/homedir/toto/share grant read (write) titi inheritable
Only the share directory is readable (and writable) by titi...
Thomas
Warwick Burrows wrote:
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]
--
+---=( 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]
