Strange ACL evaluation depending on AttributeSelection?

[Michael Ströder <michael@stroeder.com>]

HI!

Today I made a strange observation tested with release 2.4.32 and git-build
RE24 6f33e2c both with same results.

The following commands (lines wrapped herein) were all typed as user root
which gets mapped by authz-regexp to the rootdn of the database o=example
(LDAPI with SASL/EXTERNAL).

Let's check that:

# ldapwhoami
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn:uid=admin,o=example

I wanted to check ACLs applied to attribute 'sambaNTPassword' and to test
Samba logon of course. Samba logon did work when putting the Samba demon user
in a special group which has read access everywhere but it didn't when the
special Samba ACLs were to be applied. So I tried to examine a possible bug in
my ACLs but noticed unexpected results during that.

Everything looks fine with a normal search as rootdn and we see that the entry
indeed contains 'sambaNTPassword':

# ldapsearch -LLL "(&(objectclass=sambaSamAccount)(uid=wtester))"
sambaNTPassword
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: employeeNumber=42424242,ou=users,o=example
sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

But when requesting to use the authz-DN with which the Samba demon binds the
attribute is not shown which one might consider an ACL issue. Note that
sambaNTPassword is explicitly requested just like Samba correctly does it:

# ldapsearch -LLL -X "dn:uid=samba_dc_1,ou=samba,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" sambaNTPassword
SASL/EXTERNAL authentication started
SASL username: dn:uid=samba_dc_1,ou=samba,o=example
SASL SSF: 0
dn: employeeNumber=42424242,ou=users,o=example

But then I would expect this search also *not* to return attribute
'sambaNTPassword' but it does!

# ldapsearch -LLL -X "dn:uid=samba_dc_1,ou=samba,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" "*" |grep -i sambaNTPassword
SASL/EXTERNAL authentication started
SASL username: dn:uid=samba_dc_1,ou=samba,o=example
SASL SSF: 0
sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Maybe I'm doing something wrong on the command-line but I simply
don't get it... :-/

Or is there some difference in ACL handling based on  SearchRequest.attributes
(AttributeSelection)?

I have an ACL which blocks access to password attributes of disabled users by
using a filter-based ACL. Hmm, I did not try what happens when explicitly
requesting the attribute used in the filter. I have to do that tomorrow...

Ciao, Michael.