[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: (ITS#7673) rwm and bad ACL evaluation



Further testing confirms that the filter for the ACL is not being applied correctly when rwm is used. Turning the rewriteEngine off has no effect. All lines referring to rwm must be commented.

Interestingly, performing the query without specifying any attribute succeeds. All allowed attributes are returned.

ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \
 -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)"

# extended LDIF
#
# LDAPv3
# base <ou=accounts,o=cune> with scope subtree
# filter: (uid=Test.Entry)
# requesting: ALL
#

# 2, accounts, cune
dn: qmailUID=2,ou=accounts,o=cune
objectClass: pilotPerson
objectClass: qmailUser
objectClass: PureFTPdUser
cn: Test Entry
sn: Entry
uid: Test.Entry
accountStatus: active
mail: test.entry@cune.org
userClass: stu

# search result
search: 2
result: 0 Success


Specifying an allowed attribute or no attributes (1.1) causes the query to fail. For example,

ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \
 -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" cn

ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \
 -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" 1.1

# extended LDIF
#
# LDAPv3
# base <ou=accounts,o=cune> with scope subtree
# filter: (uid=Test.Entry)
# requesting: cn
#

# search result
search: 2
result: 32 No such object

# numResponses: 1


Removing the filter from the ACL allows the query to succeed.

access to dn.subtree="ou=accounts,o=cune"
  attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus
  by dn="qmailGID=306,ou=accounts,o=cune" read
  by peername.ip=127.0.0.0%255.255.255.0 read
  by peername.ip=10.0.0.0%255.255.192.0 read
  by * none


In summary, slapd is unable to apply the filter for an ACL correctly when rwm is being used and an attribute (or no attributes) is specified with the query.