It seems that your problem is caused by the fact that slapo-dynlist(5) implements compare on dynamically generated data by performing an internal search to collect info that before being used, or anyway accessed, will be subjected to further access control with the identity of the effective user. The reason an internal search is used in that case seems to be essentially related to code reuse, so slapo-dynlist(5) should be redesigned to avoid using internal searches in those circumstances, so that the correct access privilege is assessed (e.g. compare vs. search/read). Using the rootdn to generate the list, and then check access to the list itself may not be correct, because the dynamic list could become a means to circumvent access control to the actual data; think of a case where the effective user has no privileges on the actual data, but has compare, or even read access to the dynamically generated list. Then, if the list were generated as rootdn, the user would be able to compare, or even read, on data that is a derivative of otherwise inaccessible data. I would consider this a violation of data integrity.
The attached patch modifies ACL code such that the access privilege to be used can be specified (e.g. adding a o_acl_priv which is used for all checking if != ACL_NONE. I picked ACL_NONE because it's zero; ACL_INVALID_ACCESS would be more appropriate, but then we'd need to initialize all Operation structures...)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------