OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6776
Full headers

From: h.b.furuseth@usit.uio.no
Subject: Control handling in PassMod exop + ppolicy
Compose comment
Download message
State:
0 replies:
0 followups:

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.
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org