Re: ACLs for children entry

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

On Thu, 22 Mar 2012 14:22:45 +0100, Natalia <nata.cs2@gmail.com> wrote:
> I have the following tree structure in LDAP:
> ou=people,dc=example,dc=com
>   uid=user1,ou=people,dc=example,dc=com
> 
>            cn=child1,uid=user1,ou=people,dc=example,dc=com
>            cn=child2,uid=user1,ou=people,dc=example,dc=com
>    uid=user2,ou=people,dc=example,dc=com
> ..
> 
> I would like to make access in such a way: if fathers account
> (uid=user1,ou=people,dc=example,dc=com) is inactivated
> (description=inaktiv), all children become inaccessible.

Something like this, I think.  Untested, sorry.

to dn.regex=",(uid=[^,]+,ou=people,dc=example,dc=com)$"
  by set.expand="[$1]/description & inaktiv" none
  by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128 sasl_ssf=56 write
  by * +0 break

I.e. access to: any children of an uid=... entry.
  1. Look up 'description' in entry $1 ("uid=...), and
     refuse access if it matches 'inaktiv'.
  2. For other entries, ldap admin over TLS+SASL gets full access.
  3. For everyone else, skip this access statement and go
     on to check the following access 'to' statements.

Drop the regexps' initial "," to also control the uid=... entry.
Swap (1) and (2) to also give admin access to inactive subtrees.
Replace (3) with e.g. 'by * read' to instead give others read access.

> I have tried with this, but it has not functioned:
>  to dn.regex="uid=([^,]+),ou=people,dc=example,dc=com"
> filter="(description=inaktiv)" attrs=children 
>   by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128
> sasl_ssf=56 write 
>   by * none

That's not what "()" in regexps, filter, and children mean.  See
man slapd.access.  The access syntax tries to make sensible access
statements readable, but that doesn't mean any readable access
statement is sensible:-)

This is what your access statement means:

When accessing e.g. the entry "cn=child1,...", your dn.regex is checked
against the DN, and matches.  But the filter is checked against the
cn=child1 entry, not against a parent entry.  That does not match.  Nor
does attrs=children usually match - that's a pseudo-attribute which
Add/Delete/Rename check in the parent entry of the entry being added.

So this access statement is skipped, since the 'to' statement normally
does not match.  If it had matched, you'd then give write access to
ldapadmin if they use TLS and SASL.  Nobody else would get access.

-- 
Hallvard