Viewing Incoming/6776
Full headers

Major security issue: yes  no

Notes:

Notification:

Date: Tue, 04 Jan 2011 17:40:22 +0000
From: h.b.furuseth@usit.uio.no
To: openldap-its@OpenLDAP.org
Subject: Control handling in PassMod exop + ppolicy

Full_Name: Hallvard B Furuseth
Version: HEAD
OS: 
URL: 
Submission from: (NULL) (193.157.201.41)
Submitted by: hallvard


passwd_extop(op, rs) does an internal op->o_bd->be_modify(op, rs) and
then intentionally returns with sr_text, sr_ref, sr_ctrls from be_modify
intact, so the caller can send them.  By my understanding this is quite
fragile, since these SlapReply values can be invalid/out of scope after
be_modify returns.  It clashes with SlapReply cleanup effort, ITS#6758.

It does this so ppolicy can insert its controls there, after detecting
that the current be->be_modify call is actually a Password Modify exop.

Maybe passwd_extop() instead can give the Modify a response or cleanup
handler which steals any controls from the SlapReply, and reinserts them
after be_modify() returns?

OTOH - I don't know how slapd manages controls nowadays (what decides
which controls should be freed, etc) - but I notice ppolicy.c has its
very own ctrls_cleanup().  Hopefully that function is general enough
that it would be useful to move it into slapd - if it needs its own
special control handling, then maybe this issue expands to a need
for a general control handling module.  ppolicy registers its control
as valid with Password Modify, which tells Password Modify it can
steal it, etc.


One final issue: passwd.c says
		cb.sc_private = qpw;	/* let Modify know this was pwdMod,
					 * if it cares... */
and ppolicy recognizes any Modify with
	(sc->sc_response == slap_null_cb && sc->sc_private)
as the Password Modify operation.  Seems no guarantee.  I suggest to
instead set some specific passwd_<response/cleanup>_sc function which
ppolicy can recognize - maybe in addition to the current check, so a
2.4.24-compiled ppolicy can work with 2.4.23 slapd and vice versa.