Re: Subtree ACL Problem

[Adam Tauno Williams <adam@morrison-ind.com>]

So the following is correct?

defaultaccess   read
access to attr=userpassword
  by self write
  by group/organizationalRole/roleOccupant="cn=personel,ou=Groups,o=MI,c=US"
write
  by * compare
access to dn="ou=People,o=Morrison Industries,c=US"
  attrs=children,entry,uid,cn
  by group/organizationalRole/roleOccupant="cn=personel,ou=Groups,o=MI,c=US"
write
  by group/organizationalRole/roleOccupant="cn=cis,ou=Groups,o=MI,c=US" write
access to *
  by group/organizationalRole/roleOccupant="cn=cis,ou=Groups,o=MI,c=US" write

I think the list, or the FAQ, could do with a few more examples.  I'm curious
what the "attrs=children,entry" means exactly?  I can't seem to find that
anywhere in the documentation.  Why is "uid" added to it in the examples, is it
because it is the RDN attribute?  Since "cn" is my RDN attribute I added that to
the list on a hunch.

> You got it wrong, very wrong. The file is processed from top to bottom.
> As soon as an 'access to something' clause matches, no other access
> clauses are processed. Since your first clause (access to *) matches
> every records, the other clauses are never used. After the first
> matching clause is found, then the search for a matching 'by' proceeds
> from first to last in that 'access by' clause. As soon as a 'by'
> matches, the other 'by's are ignored. If no 'access by' clause matched,
> the defaultaccess clause is used.
>> I have the following access controls.
>> defaultaccess   read
>> access to *
>>   by group/organizationalRole/roleOccupant="cn=cis,ou=Groups,o=Morrison
>> Industries,c=US" write
>> access to attr=userpassword
>>   by self write
>>   by * compare
>> access to dn="ou=People,o=Morrison Industries,c=US"
>>   attrs=children,entry,uid,cn
>>   by group="cn=personel,ou=Groups,o=Morrison Industries,c=US" write
>> 
>>It all works except the last entry.  I want the group personel to be able to
>>create/delete/modify objects beneath "ou=People".  The first entry works,and
>>does grant complete control to anyone whose dn is listed as a roleoccupant 
>>in the said group.  I tried the same syntax with the last entry, as well the
>>short version shown here (I currently have the objectclass set to
>>groupofuniquenames with a uniquemember attirbute containing the DN of each
>>person),  but any attempt to perform any operations results in failure. I've
>>moved my own DN back and forth between the two groups, and bieng in the
>>first as a roleoccupant grants me access, while bieng in the second as a
>>uniquename does not.  I'm kind of stumped, because I read about this in the
>>Subtree ACL thread.