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.

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.