ando@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
Modified Files: proto-slap.h 1.695 -> 1.696 controls.c 1.181 -> 1.182 operation.c 1.76 -> 1.77
Log Message: destroy cached groups after identity change (ITS#4760)
I think the groups should not even have been cached in the first place; lookups for auth purposes usually set op->o_nocaching.
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/proto-slap.h http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/controls.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/operation.c
Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
.
Howard Chu wrote:
I think the groups should not even have been cached in the first place; lookups for auth purposes usually set op->o_nocaching.
You're right; but the point doesn't seem to be about caching during the authorization-related internal lookup; caching seems to occur earlier, while checking access to the authzTo/authzFrom attrs. There might be some issue in the authz resolution.
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 ------------------------------------------
Pierangelo Masarati wrote:
Howard Chu wrote:
I think the groups should not even have been cached in the first place; lookups for auth purposes usually set op->o_nocaching.
You're right; but the point doesn't seem to be about caching during the authorization-related internal lookup; caching seems to occur earlier, while checking access to the authzTo/authzFrom attrs. There might be some issue in the authz resolution.
The issue seems to occur in slap_sasl_check_authz(), which calls backend_attribute() to gather authzTo/authzFrom complying with access control. The point is: should "no caching" be set here or directly in backend_attribute()? It seems to me that few cases of using backend_attribute() would require caching of access control...
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 ------------------------------------------
Pierangelo Masarati wrote:
I think the groups should not even have been cached in the first place; lookups for auth purposes usually set op->o_nocaching.
Just to clear out: what's the difference between o_nocaching and o_do_not_cache? The latter seems more appropriate in this case, since in slap.h there's a comment that explicitly refers to group ACL caching.
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 ------------------------------------------
Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
I think the groups should not even have been cached in the first place; lookups for auth purposes usually set op->o_nocaching.
Just to clear out: what's the difference between o_nocaching and o_do_not_cache? The latter seems more appropriate in this case, since in slap.h there's a comment that explicitly refers to group ACL caching.
Ah, I meant o_do_not_cache. As I recall, o_nocaching is a remnant from the 2.2 syncrepl implementation - a hint to the backends that entries touched for a particular request aren't important and should not stay in the entry cache. A grep of the source tree shows that it is pretty much unused now.
-
Howard Chu -
Pierangelo Masarati