Re: Dealing with Inherited Permissions

[Michael Smith]

[EMAIL PROTECTED] wrote:

Lets say I have the following configuration:

+/users/Administrators group has <DAV:all> permissions to "/" inheritable
+/users/FileAdministrators group has <DAV:read> and <DAV:write> permissions
to "/files" inheritable

If I issue an ACL request to modify the permissions on the "/files"
resource (following the spec guidelines in section 8.1), the permissions do
not get re-created correctly.  The permissions for the "
+/users/FileAdministrators" group get re-created as non-inheritable.

I think the problem arises because retrieving the current ACL using the
PROPFIND containing the <DAV:acl> property of the "/files" resource,
returns the permissions for the "+/users/FileAdministrators" principal
without indicating they are inheritable.  I know this is different than
indicating that permissions are inherited (from another resource), but the
resulting problem is significant.

Has anyone else run into this before??  If so, how did you solve it??

Another question is how can you create an inheritable permission to send to
the server.  I have read the spec about 3 times and cannot find any
definition on how to send an ACE and indicate that it should be
inheritable??

I ran into this problem - as far as I can tell, the ACL spec does NOT specify any way to do it. There's a lot of flexibility in how ACLs are reported, but setting them is much more limited (to the point where it's not particularly useful with many permissions models, like slide's).

Mike



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