[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#7889) rwm overlay causes incorrect acl parsing
Full_Name: John Alex.
Version: 2.4.39
OS: FreeBSD 9.2-RELEASE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (62.1.253.119)
When enabling the rwm overlay on a database, even without setting any rewrite
rules, in certain cases some access rules are not evaluated correctly.
My test configuration (without the cn=schema,cn=config entries):
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: slapd.conf
olcConfigDir: slapd.d
olcArgsFile: /var/run/openldap/slapd.args
olcAttributeOptions: lang-
olcLogLevel: stats acl
olcPidFile: /var/run/openldap/slapd.pid
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/local/libexec/openldap
olcModuleLoad: {0}back_mdb
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth" manage by * break
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcSchemaDN: cn=Subschema
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth" manage
olcAddContentAcl: TRUE
olcRootDN: cn=admin,cn=config
olcRootPW:: dGVzdDEyMw==
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/db/openldap-data/main
olcSuffix: dc=example,dc=com
olcRootDN: cn=admin,dc=example,dc=com
olcDbIndex: objectClass eq
olcDbIndex: ou,uid eq
olcDbMaxSize: 4294967296
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth" manage by * break
olcAccess: {1}to dn.one="ou=people,dc=example,dc=com" filter="(ou=someunit)" a
ttrs=userPassword by * none
olcAccess: {2}to dn.subtree="ou=people,dc=example,dc=com" by dn.base="cn=suser
,ou=admins,dc=example,dc=com" read by * break
olcAccess: {3}to attrs=userPassword by anonymous auth
olcAccess: {4}to dn.base="dc=example,dc=com" by * read
olcAccess: {5}to dn.subtree="ou=people,dc=example,dc=com" by * read
olcRootPW:: dGVzdDEyMw==
dn: olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config
objectClass: olcRwmConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}rwm
-------------------------------------------------
And the contents of the main db:
dn: dc=example,dc=com
objectClass: organization
objectClass: top
objectClass: dcObject
dc: example
o: example.com
dn: ou=admins,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: admins
dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: people
dn: cn=suser,ou=admins,dc=example,dc=com
sn: -
cn: suser
objectClass: person
objectClass: top
userPassword:: dGVzdDEyMw==
dn: uid=jdoe,ou=people,dc=example,dc=com
uid: jdoe
sn: Doe
cn: John Doe
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
ou: someunit
userPassword:: dGVzdDEyMw==
-------------------------------------------------
The above rules should not allow anyone but the local root user access to the
userPassword attribute of entries under "ou=people,dc=example,dc=com" that match
the filter (ou=someunit). slapacl confirms that for user 'suser':
% slapacl -F /usr/local/etc/openldap/slapd.d/ -v -D
"cn=suser,ou=admins,dc=example,dc=com" -b
"uid=jdoe,ou=people,dc=example,dc=com"
authcDN: "cn=suser,ou=admins,dc=example,dc=com"
entry: read(=rscxd)
children: read(=rscxd)
uid=jdoe: read(=rscxd)
sn=Doe: read(=rscxd)
cn=John Doe: read(=rscxd)
objectClass=inetOrgPerson: read(=rscxd)
objectClass=organizationalPerson: read(=rscxd)
objectClass=person: read(=rscxd)
objectClass=top: read(=rscxd)
structuralObjectClass=inetOrgPerson: read(=rscxd)
entryUUID=a6478f94-80df-1033-8692-c5a9d2143987: read(=rscxd)
creatorsName=cn=admin,dc=example,dc=com: read(=rscxd)
createTimestamp=20140605092934Z: read(=rscxd)
ou=someunit: read(=rscxd)
userPassword=****: none(=0)
entryCSN=20140605093709.772129Z#000000#000#000000: read(=rscxd)
modifiersName=cn=admin,dc=example,dc=com: read(=rscxd)
modifyTimestamp=20140605093709Z: read(=rscxd)
% slapacl -F /usr/local/etc/openldap/slapd.d/ -v -D
"cn=suser,ou=admins,dc=example,dc=com" -b "uid=jdoe,ou=people,dc=example,dc=com"
userPassword/read
authcDN: "cn=suser,ou=admins,dc=example,dc=com"
read access to userPassword: DENIED
-------------------------------------------------
Requesting all attributes of the entry "uid=jdoe,ou=people,dc=example,dc=com"
yields the expected result:
% ldapsearch -LLL -H ldapi:/// -D "cn=suser,ou=admins,dc=example,dc=com" -W -x
-b "ou=people,dc=example,dc=com" "uid=jdoe"
dn: uid=jdoe,ou=people,dc=example,dc=com
uid: jdoe
sn: Doe
cn: John Doe
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
ou: someunit
However, when requesting the userPassword attribute explicitly, the rule that
blocks access to that attribute is somehow ignored:
% ldapsearch -LLL -H ldapi:/// -D "cn=suser,ou=admins,dc=example,dc=com" -W -x
-b "ou=people,dc=example,dc=com" "uid=jdoe" "userPassword"
dn: uid=jdoe,ou=people,dc=example,dc=com
userPassword:: dGVzdDEyMw==
-------------------------------------------------
Removing either the "filter=(ou=someunit)" or the "attrs=userPassword" part of
the corresponding rule results in correct parsing of the ACL in the above cases,
but in order for the full rule to work, I had to remove the rwm overlay
configuration completely (setting "rwm-rewriteEngine off" did not make a
difference).
# /usr/local/libexec/slapd -V
@(#) $OpenLDAP: slapd 2.4.39 (May 9 2014 09:26:03) $