the ACL Spec does not define how ACEs or ACLs get inherited. It only allows
the server to indicate that a certain ace is inherited from another resource.
Handling inheritance is totally left up to the server. The only thing a client
sees is that an ACE was inherited. There is no way to indicate on an ACL/ACE
that it will be inherited by children of the resource.
As a consequence, there is no way that a client can manipulate inheritance
via the standard ACL protocol.
I do not know about the slide implementation details, but the notion of
"inheritable permissions" seems to be outside the ACL spec.
Best Regards, Stefan
Am Donnerstag, 09.01.03, um 16:32 Uhr (Europe/Berlin) schrieb [EMAIL PROTECTED]:
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??
- Stan Butler
*********************************************************************** *
If you received this e-mail in error please delete it and notify the sender as soon as possible. The contents of this e-mail may be confidential and the unauthorized use, copying, or dissemination of it and any attachments to it, is prohibited.
Internet communications are not secure and Hyperion does not, therefore, accept legal responsibility for the contents of this message nor for any damage caused by viruses. The views expressed here do not necessarily represent those of Hyperion.
For more information about Hyperion, please visit our Web site at www.hyperion.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
