The way I've found to get this to work is to add a grant ACE for /roles/root before adding the deny ACE for /roles/user. It takes more effort, but it works...
-James On Fri, 2004-10-01 at 09:26, Nick Longinow wrote: > I figured this out, to the extent that I keep the inheritance as described, > but when I create a collection that must be invisible to /roles/user, I just > change the Ace for that principal on that new collection to 'negative=true', > execute an aclMethod with the new Ace array, and presto, elements of > /roles/user are not able to access the resource. > > But, but, but, I still want /roles/root to be able to access the resource > (for admin purposes). However, since root is a member of /roles/user, now > root is excluded by the action just described above. > Is there a way to exclude /roles/user and still allow /roles/root access ? > The Dav spec, or Slide documentation, says that in the case of a conflicting > permission (as here, where /roles/root has DAV:all and /roles/user has none) > we end up with the /roles/user taking precedence (apparently). > > -----Original Message----- > From: Nick Longinow [mailto:[EMAIL PROTECTED] > Sent: Friday, October 01, 2004 12:13 PM > To: 'Slide Users Mailing List' > Subject: If ACL-inh="root", why cant user authenticate ? > > Help with a basic Slide/Dav question ? > > In domain.xml: > Set /files acl-inheritance to 'root'. > Set root permissions to allow /roles/user permission "all" but have that > permission be inheritable=false. > > <permission action="all" subject="/roles/root" inheritable="true"/> > <permission action="all" subject="all" inheritable="false"/> > <permission action="all" subject="/roles/user" inheritable="true"/> > > Create user under /users, add a password prop, and add to /roles/user. > --> User cant login. !! > > Now, Change inheritable on root permissions (above) to be true. > > User can login! I don't understand this. I don't want to have to set the > permissions on the /roles/user to be inheritable because I am trying to > limit the access of the principal /roles/user to deeper branch nodes, and > only grant access to other principals, but if this inheritance is set to > true, then collections constructed down the line from /files will get this > permission, which I don't want it to have (and you cant remove it from that > deeper collection node...) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
