Subject: Re: [ACL] RFC 3744: Modifying ACEs

From: Julian Reschke <[email-masked]>
Date: Sat, 05 May 2007 13:20:50 +0200

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

---

From: "Tim Olsen" <[email-masked]>
Date: Sat, 5 May 2007 21:36:10 -0400

In the implementations we're working on here at Lime Wire, we always
put the protected ACEs up front and the inherited ACEs last.  This way
one cannot override a protected ACE - with the exception of protected
ACEs that are inherited because they get grouped together with the
inherited ACEs.

-Tim

---

From: Werner Donné <[email-masked]>
Date: Sun, 06 May 2007 18:16:30 +0200

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:

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: "Tim Olsen" <[email-masked]>
Date: Sun, 6 May 2007 14:45:14 -0400

> the appropriate permissions can overwrite the property after the

I believe the lock is necessary because the acl property *is*
completely overwritten.  To make a change, a client must first read
the acl property.  To ensure that it does not overwrite someone else's
change when writing the acl property back, the client should grab a
lock.  Otherwise, another client could have changed the acl property
between the first client's PROPFIND and ACL requests.

-Tim

---

From: Werner Donné <[email-masked]>
Date: Mon, 07 May 2007 13:53:06 +0200

There is another problem with not being able to identify
an ACE. Inheritance won't work. Consider the following
scenario:

resource1 has an ACL with one ACE: "grant read to Jack".
resource2 inherits this ACE.
Now the ACL of resource1 is changed to have two ACEs:
"grant read to John" and "grant read to Paul".

What should happen to resource2? There seem to be three
possibilities:

1) Jack became John and Paul was added, resource2 continues to inherit the ACE.
2) Jack became Paul and John was added, resource2 continues to inherit the ACE.
3) Jack was removed and John and Paul were added, resource2 loses the inherited ACE.

Werner.

---

From: Jake Baumgarten <[email-masked]>
Date: Sun, 6 May 2007 18:12:30 -0700

Apple's .Mac WebDAV server does something very similar.  However,  
protected ACEs are always protected and cannot be overridden by user  
ACEs.  We have a "third" class of ACEs that are inherited, but not  
protected.  While a client can see the effect due to ordering, there  
is no way to distinguish these ACEs without non-standard query  
extensions.

-Jake

JS "Jake" Baumgarten
Manager, iDisk Engineering
Apple, Inc.