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) $
alexoz66@gmail.com wrote: > When enabling the rwm overlay on a database, even without setting any rewrite > rules, in certain cases some access rules are not evaluated correctly. I did not look into your posting in detail. But could you please check whether this setting helps: rwm-drop-unrequested-attrs no Ciao, Michael.
Hi Michael, I tried to enable this setting using the following ldif: dn: olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config changetype: modify add: olcRwmDropUnrequested olcRwmDropUnrequested: FALSE but I get the following error: modifying entry "olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcRwmDropUnrequested' not allowed Looking at the schema it seems that the attribute olcRwmDropUnrequested is not part of the olcRwmConfig object class (or any other object class for that matter). On 02/07/2014 08:48 μμ, Michael Ströder wrote: > alexoz66@gmail.com wrote: >> When enabling the rwm overlay on a database, even without setting any rewrite >> rules, in certain cases some access rules are not evaluated correctly. > > I did not look into your posting in detail. > > But could you please check whether this setting helps: > > rwm-drop-unrequested-attrs no > > Ciao, Michael. >
changed notes changed state Open to Test moved from Incoming to Software Bugs
michael@stroeder.com wrote: >But could you please check whether this setting helps: > >rwm-drop-unrequested-attrs no It does. This is another case of ITS#6057; the ACL filter can only be evaluated if the filter attribute is included in those passed through by rwm, otherwise it is just skipped. The larger issue (should ACL evaluation assume the whole entry is available?) seems to still be unaddressed. I don't understand yet why rwm filters the attributes on its own by default, but I'm sure there's a reason. alexoz66@gmail.com wrote: >modifying entry "olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config" >ldap_modify: Object class violation (65) > additional info: attribute 'olcRwmDropUnrequested' not allowed > >Looking at the schema it seems that the attribute olcRwmDropUnrequested >is not part of the olcRwmConfig object class (or any other object class >for that matter). This is fixed in git master now.
changed notes changed state Test to Release
see ITS#6057 missing olcDropUnrequested fixed in master fixed in RE25 fixed in RE24
changed notes changed state Release to Closed