Thank you Peter and Stefan.
I had been racking my brain for a few days trying to figure out how the
server could interpret permissions being assigned as either inheritable or
not. After tracing through the source code in the ACL method, we learned
that Slide always assumes permissions being passed in a reauest will be
inheritable. The problem arose when we set a non-inheritable permission
for a role (through the Domain.xml) on a resource, and it got changed to an
inheritable permission the first time an ACL request was issued on that
resource. Now that I know this, it makes sense why the Webdav ACL draft 9
specification was implemented for dealing with ACE evaluation.
Thanks again for the help.
- Stan
"Nevermann, Dr.,
Peter" To: "'Slide Users Mailing
List'" <[EMAIL PROTECTED]>
<Peter.Nevermann@soft cc:
wareag.com> Subject: RE: Dealing with
Inherited Permissions
01/10/2003 04:48 AM
Please respond to
"Slide Users Mailing
List"
> I do not know about the slide implementation details, but the
> notion of
> "inheritable permissions" seems to be outside the ACL spec.
Our understanding is the same as described by Stefan. There is no notion of
"inheritable permissions", neither in Slide. The Slide implementation is
such that, basically, ACEs are inherited over the namespace hierarchy.
Regards,
Peter
> -----Original Message-----
> From: Stefan Eissing [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 10, 2003 10:14
> To: Slide Users Mailing List
> Subject: Re: Dealing with Inherited Permissions
>
>
> Stan,
>
> 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]
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
************************************************************************
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]>
