masarati@aero.polimi.it wrote:
The patch is the result of my reading in 5 minutes a single portion of a spec I read in detail years ago, so my interpretation could not be the most correct.
But your interpretation makes sense: E.g. system accounts most times do not need to change their own password. And for security reasons you might want to avoid that. Think of a the case where the password of a more exposed system is known by an attacker (which is likely a very bad case anyway). But at least the attacker should not be able to disable this service by setting a new password.
Yes, this can be done with ACLs. But you might already have a password policy assigned to this special system accounts because you don't want the system accounts' password to expire. So adding an extra ACL is more work especially if system accounts are spread across a more complicated DIT.
Well, as a counter-example, if security is compromised, then setting pwdAllowUserChange to FALSE would only prevent password modification for users that fall under that password policy, while others would need to be protected anyway using ACLs. And if security is seriously compromised, none of these would work, because rootdn circumvents all checks.
So giving different orthogonal means to obtain similar but not identical effects sounds to me making things more complicated than they ought to be. Given the fact that pwdAllowUserChange is a gross subset of ACLs, I'd rather discourage its usage through clear documentation than try to make it conform to some or some other interpretation of the specs.
p.