Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody

[masarati@aero.polimi.it]

> 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.