[Resending this as the first one didn't seem to appear on the mailing list, I apologize if this creates a duplicate.]
Hi,
I believe I have found 3 issues related to the rwm overlay and the extra_attrs (or olcExtraAttrs) setting written to fix the issues described in ITS#6513 ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6513;selectid=6513;...). The description is long but I tried to provide as much information as possible. I am hoping someone can test and confirm the issues or tell me what I'm doing wrong if there in fact is no issue.
I'm running version 2.4.32 on Ubuntu 10 and Debian Squeeze.
1) The documentation in the slapd-config manpage is incorrect. The olcExtraAttrs setting is said to be a global configuration setting when in reality it seems to be database specific. In the slapd.conf manpage, the corresponding setting (extra_attrs) is listed as being database-specific. I believe that is correct although I have not checked it.
2) olcExtraAttrs does not seem to work with the rwm overlay (like in ITS#6513). With the rwm overlay present, ACIs are not evaluated when requesting a specific attribute, regardless of whether olcExtraAttrs is specified or not. In order to apply the ACI, you can pass the ACI attribute name in the search. I'm providing a configuration file that can be used to reproduce the problem as well as some search examples to demonstrate the issue.
----Configuration file----
dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /usr/local/var/run/slapd.pid olcArgsFile: /usr/local/var/run/slapd.args #olcLogLevel: -1 olcToolThreads: 1
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=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 olcRequires: authc
dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema
include: file:///usr/local/etc/openldap/schema/core.ldif
dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleload: back_hdb olcModuleLoad: rwm
dn: olcOverlay=rwm,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm
dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: hdb olcSuffix: dc=example,dc=com olcDbDirectory: /var/lib/ldap olcRootDN: cn=admin,dc=example,dc=com olcRootPW: pass olcDbConfig: set_cachesize 0 2097152 0 olcDbConfig: set_lk_max_objects 1500 olcDbConfig: set_lk_max_locks 1500 olcDbConfig: set_lk_max_lockers 1500 olcExtraAttrs: OpenLDAPaci olcAccess: to attrs=userpassword by anonymous auth olcAccess: to dn.base="dc=example,dc=com" by * search olcAccess: to * by self manage by dynacl/aci=OpenLDAPaci manage
----Note----
To disable the rwm overlay, comment the following 4 lines in the config:
dn: olcOverlay=rwm,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm
----Test data----
dn: dc=example,dc=com objectClass: dcObject objectClass: top objectClass: organization dc: example o: example
dn: cn=a,dc=example,dc=com objectClass: top objectClass: person cn: a sn: a userPassword: pass
dn: cn=b,dc=example,dc=com objectClass: top objectClass: person cn: b sn: b userPassword: pass OpenLDAPaci: 1#entry#grant;r,s,c;[all]#access-id#cn=a,dc=example,dc=com
----Search examples----
Without rwm, requesting the whole object (works as expected): ldapsearch -x -D cn=a,dc=example,dc=com -w pass -b cn=b,dc=example,dc=com
# b, example.com dn: cn=b,dc=example,dc=com objectClass: top objectClass: person cn: b sn: b
# numResponses: 2 # numEntries: 1
Without rwm, requesting an attribute (works as expected): ldapsearch -x -D cn=a,dc=example,dc=com -w pass -b cn=b,dc=example,dc=com sn
# b, example.com dn: cn=b,dc=example,dc=com sn: b
# numResponses: 2 # numEntries: 1
With rwm, requesting the whole object (works as expected): ldapsearch -x -D cn=a,dc=example,dc=com -w pass -b cn=b,dc=example,dc=com
# b, example.com dn: cn=b,dc=example,dc=com objectClass: top objectClass: person cn: b sn: b
# numResponses: 2 # numEntries: 1
With rwm, requesting an attribute (notice the object is not returned here): ldapsearch -x -D cn=a,dc=example,dc=com -w pass -b cn=b,dc=example,dc=com sn
# numResponses: 1
With rwm, requesting an attribute and openldapaci (works as expected): ldapsearch -x -D cn=a,dc=example,dc=com -w pass -b cn=b,dc=example,dc=com sn openldapaci
# b, example.com dn: cn=b,dc=example,dc=com sn: b OpenLDAPaci: 1#entry#grant;r,s,c;[all]#access-id#cn=a,dc=example,dc=com
# numResponses: 2 # numEntries: 1
3) The last issue came up when I was attempting to set up a certain kind of access control logic. It is highly similar to the previous problem but it doesn't involve ACIs. The issue is caused by the rwm overlay somehow blocking the ACL from accessing unrequested attributes just like in the previous case. olcExtraAttrs was created to fix this issue but I assume it would not fully solve the problem in my case. I have naturally not been able to test it due to the fact that I haven't gotten olcExtraAttrs to work.
The access control logic I was attempting to set up was such that objects could contain 2 new attributes: 'rights' and 'requiredRights', both being multivalued strings. 'requiredRights' tells what rights are required to access the object in question, and 'rights' tells what rights each object has. If the user's 'rights' and the target objects 'requiredRights' have at least one common string, access is granted. Fairly simple. The ACL used to evaluate access is as follows:
to * by set="this/requiredRights & user/rights" read
This method works unless I use the rwm overlay. I'm guessing the attributes required to evaluate the ACLs are somehow dropped and cannot be used. olcExtraAttrs would (if it worked) automatically add the needed attributes to the target object but, to my understanding, not to the user object. The user's attributes would however be needed to evaluate the set shown earlier.
The trick used in the last of the previously shown search examples does not work in this case. I can provide requiredRights and rights as additional attributes in the search and I assume requiredRights is returned for access control to use but rights isn't as it is an attribute of the user object. I don't have a cleaned-up version of the config at this time but one could be created if needed.