a "new password" failure in a requisite PAM module does not prevent setting that password

If a PAM module fails due to bad "new" password (too simple), the following modules still get called, and set the bad passwords, and this even if module marked as requisite (return to application immediately on error).

This can be seen both by cracklib, and by libpam_unix's own builtin checks.

Example:

password requisite pam_cracklib.so retry=6 minlen=6 difok=3
password required pam_unix.so nullok md5

If a password that is too simple is entered, pam_cracklib complains, but processing still moves on (causing pam_unix to set that bad password).

Here is an example of the dialog:

Changing password for testens.
(current) UNIX password:
New UNIX password:
BAD PASSWORD: is too similar to the old one
New UNIX password:
BAD PASSWORD: is too similar to the old one
New UNIX password:
BAD PASSWORD: is too similar to the old one
New UNIX password:
BAD PASSWORD: is too similar to the old one
New UNIX password:
BAD PASSWORD: is too similar to the old one
New UNIX password:
BAD PASSWORD: is too similar to the old one
Enter new UNIX password:
Retype new UNIX password:
passwd: Authentication token manipulation error
passwd: password unchanged

However, despite the display "password unchanged", it is indeed unchanged.

The problem happens independently of whether pam_cracklib is declared as required or requisite.

The problem also happens if the failing module is pam_unix (due to its own builtin minimal password strength check) and is followed by another module (such as pam_ldap). In that case the situation becomes much worse, because here we'll end up with the LDAP password changed, but the Unix password still equal to the old one. In such a situation, the user may no longer be able to change his password, because the "old" password no longer can match both LDAP and Unix.

Due to the fact that different "error raising" modules are impacted (pam_cracklib and pam_unix), and that different "password setting" modules are impacted (pam_unix and pam_ldap), I believe that the cause must lie within PAM itself, rather than the modules.