Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database

[hyc@symas.com]

mark.cave-ayland@siriusit.co.uk wrote:
> Full_Name: Mark Cave-Ayland
> Version: 2.4.23
> OS: Linux/Debian
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (81.187.123.11)
>
>
> Hi all,
>
> We have an issue on one of our production systems whereby openldap is not
> enforcing the ACLs on a back-perl subordinate database.

Keep in mind, this is back-perl's documented behavior.

 >>>
ACCESS CONTROL
        The perl backend does not honor any of  the  access  control  semantics
        described  in  slapd.access(5);  all access control is delegated to the
        underlying PERL scripting.  Only read (=r) access to the entry  pseudo-
        attribute  and to the other attribute values of the entries returned by
        the search operation is honored, which is performed by the frontend.
<<<

Treating this as an enhancement request.

> In this particular system, the membership of certain groups stored within LDAP
> is determined by some customised logic in a Perl module which dynamically
> generates LDAP objects with posixGroup/groupOfNames entries conditionally based
> upon the values of existing LDAP attributes within the tree. However, since
> these internal LDAP attribute lookups can be quite slow, we wish to hide them
> from all but a small minority of bind DNs. Unfortunately what we are finding is
> that the back-perl module is not respecting the ACLs in slapd.conf.
>
> The following files can be used to reproduce this issue with openldap 2.4.23:
>
> http://pastebin.siriusit.co.uk/perlacl/slapd.conf
> http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif
> http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm
>
> The password for both the "cn=admin,dc=my-domain,dc=com" and the
> "cn=restricted,dc=my-domain,dc=com" DNs is secret.
>
> The ACLs in the above slapd.conf look like this:
>
> access to dn.subtree="ou=perl,dc=my-domain,dc=com"
>          by dn="cn=admin,dc=my-domain,dc=com" read
>          by dn="cn=restricted,dc=my-domain,dc=com" none
>
> access to dn.subtree="ou=hidden,dc=my-domain,dc=com"
>          by dn="cn=admin,dc=my-domain,dc=com" read
>          by dn="cn=restricted,dc=my-domain,dc=com" none
>
> access to *
>          by dn="cn=admin,dc=my-domain,dc=com" write
>          by dn="cn=restricted,dc=my-domain,dc=com" read
>          by * auth
>
> Using these ACLs, I would expect that cn=admin should be able to read the whole
> directory, whereas cn=restricted should not be able to see either the
> "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com"
> DN subtree.
>
> However, performing an LDAP search binding as cn=restricted gives the following
> output:
>
> build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D
> 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW
> Enter LDAP Password:
> dn: dc=my-domain,dc=com
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o:: bXlkb21haW4uY29tIA==
> dc: my-domain
>
> dn: ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: real
>
> dn: ou=realtest1,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest1
>
> dn: ou=realtest2,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest2
>
> dn: ou=realtest3,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest3
>
> dn: ou=realtest4,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest4
>
> dn: ou=realtest5,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest5
>
> dn: cn=restricted,dc=my-domain,dc=com
> objectClass: simpleSecurityObject
> objectClass: organizationalRole
> cn: restricted
> description: restricted user
> userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9
>
> dn: cn=admin,dc=my-domain,dc=com
> objectClass: simpleSecurityObject
> objectClass: organizationalRole
> cn:: YWRtaW4g
> description: admin user
> userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9
>
> dn: ou=perltest5,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest5
>
> dn: ou=perltest4,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest4
>
> dn: ou=perltest3,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest3
>
> dn: ou=perltest2,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest2
>
> dn: ou=perltest1,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest1
>
>
> In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden
> from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree
> is not.
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/