masarati@aero.polimi.it wrote:
masarati@aero.polimi.it wrote:
OTOH, by strictly interpreting the way its use is discussed in the draft, it should only apply to attempts by "self" to modify the password, so a modification performed by a different identity (provided ACLs permit it) should not be affected.
Yes, that's my understanding too.
Then the patch is trivial:
diff --git a/servers/slapd/overlays/ppolicy.c b/servers/slapd/overlays/ppolicy.c index 6a693ac..d9afac9 100644 --- a/servers/slapd/overlays/ppolicy.c +++ b/servers/slapd/overlays/ppolicy.c @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs )
if (be_isroot( op )) goto do_modify;
if (!pp.pwdAllowUserChange) {
/* NOTE: according to draft-behera-ldap-password-policy* pwdAllowUserChange == FALSE only prevents pwd changes* by the user the pwd belongs to (ITS#7021) */if (!pp.pwdAllowUserChange&& dn_match(&op->o_req_ndn,&op->o_ndn)) { rs->sr_err = LDAP_INSUFFICIENT_ACCESS; rs->sr_text = "User alteration of password is not allowed"; pErr = PP_passwordModNotAllowed;If there's consensus, I'll commit it.
Seems like a pointless change. You must set ACLs for this type of modification to be allowed. Since you must set ACLs anyway, there is no good reason to use the pwdAllowUserChange policy setting in the first place. In general the pwdAllowUserChange option is only useful on systems that do not already provide fine grained access controls.