Hide Forgot
The 'passwd' command doesn't use the 'auth' PAM stack, only the 'password' one, and relies on individual pam modules to perform authentication. This is fine when there is only one authentication backend, but performs oddly when they are multiple ones, as it defeats the purpose of having a single authentication strategy. For instance, the following configuration is expected to result in consistant local-first, sssd-second authentication strategy: file /etc/pam.d/passwd: auth substack system-auth password substack system-auth file /etc/pam.d/system.auth: auth required pam_env.so auth sufficient pam_tcb.so shadow nullok prefix=$2a$ count=8 auth sufficient pam_sss.so use_first_pass auth required pam_deny.so password required pam_cracklib.so retry=3 password sufficient pam_tcb.so use_authtok try_first_pass shadow write_to=shadow nullok prefix=$2a$ count=8 password sufficient pam_sss.so use_authtok try_first_pass password required pam_deny.so However, it doesn't work, as the 'auth 'stack is ignored, and using the command result for a ldap-based account result in the following output: [guillomovitch@haiku ~]$ passwd Changing password for user guillomovitch. Changing password for guillomovitch. (current) UNIX password: Current Password: ... The first password prompt is due to pam_tcb module not able to retrieve any already entered credentials, and the second is due to pam_sssd for the same reason, despite the previous one was supposed to keep it... Having 'passwd' command use the standard 'auth' stack would result in a more expectable result. I didn't encountered this issue on a fedora or redhat distribution (mageia, if that matters), but the 'passwd' homepage ask to report issues there.
Tomáš, what do you think? It seems to me that the behavior described is likely to be simply a bug within a specific PAM module (whatever credential-retrieval or password-reuse a module can do in the “auth” stack, it should be able to do exactly the same thing in the “password stack” as well).¹ And changing the semantics of the “password” stack after all these decades seems pretty risky, all the modules designed to only run one of their callbacks would suddenly have another one called as well. ¹The description suggests that PAM modules are simply not storing the entered passwords even if they should do so; nothing about changing the stack would inherently prevent that kind of bug—but that’s just me guessing without looking at the code; can we first establish whether this should be treated as a design problem or as a module bug.
Yes, the description is pretty unclear as for whether the fix would be a true fix and if it would really fix anything. To me it seems the design decision to put the pre-authentication into the password stack was pretty unfortunate but we have to live with it. I think this decision was done so the stored password tokens do not have to be kept in the library when the pam_...() call returns to application. I suppose the real fix should be in pam_tcb password stack handling. So I would close it as NOTABUG.
Thanks, closing. Guillaume, feel free to reopen this bug against a specific PAM module if Red Hat bugzilla is the appropriate venue for filing bugs against it, or just file a new one against a specific module if that is easier.
To keep password in library memory between calls to various stacks is exactly the strategy used by PAM modules such as pam_gnome_keyring or pam_mount to retrieve a password in 'auth' stack, and using it in 'session' stack to unlock some specific feature with user login password. So, what should prevent the password executable to first call the 'auth' stack to perform standard user authentication, then calling the 'password' stack to perform password change, in a similar fashion ? And I'm not asking to change PAM library behavior here, just the one of a single standalone executable. Indeed, there is also an issue in pam_tcb not being able to store retrieved password in memory for later use (interestingly enough, that's not the case for pam_unix), but that's a different problem: one should expect than an executable designed around PAM use its dedicated authentication workflow, not to short-circuit it. Independently of your final decision about fixing this issue or not, please consider the attached patch, whose only purpose is to make the current situation more explicit for the poor sysadmin trying to figure what is the problem.
Created attachment 1112575 [details] forementioned patch
Yes, that patch should be applied for clarity.
(In reply to Guillaume Rousse from comment #4) > And I'm not asking to change > PAM library behavior here, just the one of a single standalone executable. That’s really the same thing. First, passwd is a really thin wrapper around PAM. It should do precisely what PAM says a password change program should do; which is why I have asked Tomáš what is the right thing to do. Second, for most purposes, passwd is the canonical password change program (probably the most common way to change a password, and one of the few programs every PAM module is tested against), so if passwd changes, other password change programs should change equivalently, i.e. changing passwd is fairly close to de facto changing the PAM library behavior. > Independently of your final decision about fixing this issue or not, please > consider the attached patch, whose only purpose is to make the current > situation more explicit for the poor sysadmin trying to figure what is the > problem. Great idea, applied. Thank you!