Univention Bugzilla – Bug 53130
Obsolete ?entryDN? in UCS@school set-style LDAP ACLs slows down ACL performance
Last modified: 2021-04-23 17:48:53 CEST
The set-style LDAP ACLs in UCS@school which make use of ldap:/// search expansion look slightly suboptimal to me, as they specify things like by set="this/ucsschoolSchool & ([ldap:///]+user/entryDN+[?entryDN?base?<some-LDAP-filter>])/ucsschoolSchool" write According to the OpenLDAP FAQ the dereferenced LDAP URL [ldap:///]+user/entryDN+[?entryDN?base?<some-LDAP-filter>])/ucsschoolSchool doesn't only expand to the value of ucsschoolSchool but additionally to the value of entryDN. I can see that with log level "acl" too. Those two values are vompated against the school ou of the target (this/ucsschoolSchool). Clearly the entryDN will not match in that comparison. So I'd propose to optimize those acls by removing the explicit "entryDN" from the LDAP URL like this: by set="this/ucsschoolSchool & ([ldap:///]+user/entryDN+[??base?<some-LDAP-filter>])/ucsschoolSchool" write Probably it doesn't cost much performance, but I haven't measured how this affects a master /primary in a large school environment.
Created attachment 10694 [details] proposal1.patch
More detailed information about the ldap-search: https://www.openldap.org/faq/data/cache/1133.html
It seems the '?entryDN?' is unnecessary. It will be added to the result attributes of the search. It will however not be used for comparison, so it is merely a small memory loss. Those ACLs are only used when an OU Admin or Teacher is logged into the UMC on the Primary Node and is manually administrating users/classes/workgroups. The ACLs are not installed on the replication nodes. So this is not performance relevant. Still it is unnecessary and the ACLs are difficult to read already. So Sönke and I concur that the ACLs should be modified like the OP suggests.