W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2007

Re: [ACL] RFC 3744: Modifying ACEs

From: Werner Donné <werner.donne@re.be>
Date: Sun, 06 May 2007 18:16:30 +0200
Message-ID: <463DFF5E.9090702@re.be>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: acl@webdav.org, WebDAV <w3c-dist-auth@w3.org>

The implementation note is also in contradiction with the second
paragraph of the section, which says the current user might only
see and update a subset of the ACEs (visible ACEs).

In my opinion it should be allowed to include inherited ACEs in
the request body, otherwise it is not possible to create an
inheritance link in a portable way. It should only be verified
that the ACE exists in the referred resource and that this
resources itself exists of course. This would require two additional
preconditions.

I think the specification should state that the ACL method assigns
a new value to the "acl" property. This implies all the ACEs should
be present, also the protected and the inherited ones. The server
should verify the protected ACEs are still in place. The "modification
of an ACE" should not exist as a notion.

I have also a remark about the third paragraph of section 8.1, which
says:

"In order to avoid overwriting DAV:acl changes by another client, a
client SHOULD acquire a WebDAV lock on the resource before retrieving
the DAV:acl property of a resource that it intends on updating."

This doesn't add any value, because you can't modify individual ACEs
due to the lack of an addressing method. If the "acl" property
is always updated completely a lock is not needed. Any client with
the appropriate permissions can overwrite the property after the
lock has been released.

Regards,

Werner.

Julian Reschke wrote:
> 
> Werner Donné wrote:
>> I have read that paragraph, but it doesn't solve much. What happens
>> if the client leaves the protected and inherited ACEs in the acl
>> element? From the evaluation procedure it follows there is an order
>> in the ACEs. Since protected and inherited ACEs do not necessarily
>> come first, they have to be included in the request body of the ACL
>> method. Leaving them out would require a way to match old and new
>> ACEs in order to find back the correct positions.
> 
> Yes, agreed (now that you mention it :-).
> 
>> On the other hand, if protected and inherited ACEs are not allowed
>> to be present, there should be corresponding preconditions for the
>> ACL method.
> 
> I have to confess that I'm not sure what the spec tries to say here, nor 
> how it is implemented in practice.
> 
> This definitively requires research and feedback from implementors.
> 
> Best regards, Julian
> 
> 

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
Received on Sunday, 6 May 2007 16:16:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT