Password changing fails when "krb5" pam-config is not first

[Daniel Richard G.]

This concerns libpam-krb5 3.15-1 in Karmic.

If you use the "krb5" profile for pam-auth-update, password changing works correctly---unless another profile goes above it, and the "Password" clause is used instead of "Password-Initial". (I simulated this by bumping the priority down to 255, putting it immediately after the "unix" profile.) Then you get

$ passwd
passwd: Authentication information cannot be recovered
passwd: password unchanged

The problem is in passing "use_authtok" to pam_krb5. Comparatively, try_first_pass/use_first_pass/nothing at least allows the "Current Kerberos password:" prompt to come up.

[Russ Allbery (rra-debian)]

"Daniel Richard G." <email address hidden> writes:

> This concerns libpam-krb5 3.15-1 in Karmic.

Looks like Launchpad for some reason filed the bug against
kerberos-configs instead. I'll move it.

> If you use the "krb5" profile for pam-auth-update, password changing
> works correctly---unless another profile goes above it, and the
> "Password" clause is used instead of "Password-Initial". (I simulated
> this by bumping the priority down to 255, putting it immediately after
> the "unix" profile.) Then you get

> $ passwd
> passwd: Authentication information cannot be recovered
> passwd: password unchanged

> The problem is in passing "use_authtok" to pam_krb5. Comparatively,
> try_first_pass/use_first_pass/nothing at least allows the "Current
> Kerberos password:" prompt to come up.

This was fixed in 4.0-1. The fix would need to be backported to karmic.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Steve Langasek (vorlon)]

lucid has libpam-krb5 4.2-1, so marking as resolved for the development release. If this is important to have fixed for karmic (with lucid release a little over a month out I have no opinion on this), we can open a karmic task and process an SRU.

[Daniel Richard G. (skunk)]

Russ, there was no Launchpad weirdness going on; I filed the bug against kerberos-configs, since I thought that's where Kerberos-config-related bugs were supposed to go. (E.g. bug #369575 was moved there.) But of course, it concerns a file in the libpam-krb5 package.

What was the fix, then? Was it a code issue, or should the config have used one of the other options?

I'm not going to press for a backport, since I'm using a custom profile anyway---just wanted to make sure this didn't fly under your radar due to the high Priority number.

[Russ Allbery (rra-debian)]

"Daniel Richard G." <email address hidden> writes:

> Russ, there was no Launchpad weirdness going on; I filed the bug against
> kerberos-configs, since I thought that's where Kerberos-config-related
> bugs were supposed to go. (E.g. bug #369575 was moved there.) But of
> course, it concerns a file in the libpam-krb5 package.

Oh, okay. kerberos-configs is actually a regular source package that
provides the package krb5-config. It's only responsible for
/etc/krb5.conf and the logic to generate it, not for other configuration.

> What was the fix, then? Was it a code issue, or should the config have
> used one of the other options?

It wa a code issue. pam-krb5 had an incorrect implementation of
use_authtok due to my misunderstanding of the Linux PAM documentation,
which was fixed in 4.0 by changing the meaning of several options to more
closely match the intended behavior.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Daniel Richard G. (skunk)]

Ah, thanks for clarifying, on both counts. So it's not that use_authtok was the wrong option to use after all.

[Russ Allbery (rra-debian)]

"Daniel Richard G." <email address hidden> writes:

> Ah, thanks for clarifying, on both counts. So it's not that use_authtok
> was the wrong option to use after all.

Correct. use_authtok should not affect the handling of the current
password, only the new password. pam-krb5 incorrectly applied it to both.
In 4.0 and later, the current password handling is controlled by
{try,use,force}_first_pass only and use_authtok affects only the new
password in the password change group, which then works correctly with how
pam-auth-update works (and what Linux PAM says).

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>