Bug 1296336

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!