[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;usearchives=1). 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.