Re: Subtree ACL Problem

[Patrick Timmons <ptimmons@courriel.polymtl.ca>]

Hi.

I wasn't thorough enough in my previous explanation. Slapd will process
the acls for each attributes in the record. The first line in the trace
says that slapd is looking for access rights to attribute 'mobile' for
record 'cn=Adam Williams,ou=People,o=Morrison Industries,c=US'. Since
line #3 in your acl file doesn't mention attribute 'mobile' but mention
other attributes, the statement is not used, which leads to statement #4
to be evaluated and selected since the 'to' matches.


Adam Tauno Williams wrote:
> 
> >At this point, you may want to use the debugging options of slapd. You can
> >start with '-d 128' and check how slapd uses your ACL statements.
> 
> Ok, sounds cool.  I'm stumped again,  I get the following output:
> ----------------------------------------------------------------------
> => acl_get: entry (cn=Adam Williams,ou=People,o=Morrison Industries, c=US) attr
> (mobile)
> <= acl_get: [4] backend acl cn=Adam Williams,ou=People,o=Morrison Industries,
> c=US attr: mobile
> => acl_access_allowed: write access to entry "cn=Adam
> Williams,ou=People,o=Morrison Industries, c=US"
> => acl_access_allowed: write access to value "6163401149" by "CN=ADAM
> WILLIAMS,OU=PEOPLE,O=MORRISON INDUSTRIES,C=US"
> <= ldbm_back_group: "CN=ADAM WILLIAMS,OU=PEOPLE,O=MORRISON INDUSTRIES,C=US" not
> in "CN=CIS,OU=GROUPS,O=MORRISON INDUSTRIES,C=US": roleOccupant
> <= acl_access_allowed: denied by default (no matching by)
> ------------------------------------------------------------------------
> Which tells me it is using access rule #4 which is:
> ------------------------------------------------------------------------
> access to *
>   by group/organizationalRole/roleOccupant="cn=cis,ou=Groups,o=Morrison
> Industries,c=US" write
> ------------------------------------------------------------------------
> so the interpretation is correct, I should not have write access.  What
> I don't understand is why it doesn't match rule #3 for which I've
> tried both:
> -------------------------------------------------------------------------
> access to dn=".*,ou=People,o=Morrison Industries,c=US"
>   attrs=children,entry,uid
>   by group/organizationalRole/roleOccupant="cn=personel,ou=Groups,o=Morrison
> Industries,c=US" write
>   by group/organizationalRole/roleOccupant="cn=cis,ou=Groups,o=Morrison
> Industries,c=US" write
> -----and-----------------------------------------------------------------
> access to dn="ou=People,o=Morrison Industries,c=US"
>   attrs=children,entry,uid
>   by group/organizationalRole/roleOccupant="cn=personel,ou=Groups,o=Morrison
> Industries,c=US" write
>   by group/organizationalRole/roleOccupant="cn=cis,ou=Groups,o=Morrison
> Industries,c=US" write
> -------------------------------------------------------------------------
> The data in "cn=personel,ou=Groups,o=Morrison Industries,c=US" is:
> 
> cn=personel,ou=Groups,o=Morrison Industries, c=US
> cn=personel
> gidnumber=238
> memberuid=dcommire
> memberuid=kjohnsto
> memberuid=ablood
> allowprimary=Y
> creatorsname=cn=Manager, o=Morrison Industries, c=US
> createtimestamp=20000719041914Z
> roleoccupant=cn=Adam Williams,ou=People,o=Morrison Industries,c=US
> modifytimestamp=20000725094557Z
> modifiersname=cn=Manager, o=Morrison Industries, c=US
> objectclass=posixGroup
> objectclass=top
> objectclass=organizationalRole

-- 
P.Timmons, service informatique