pam-auth-update loses user-specified module options if the module name has a digit in it (pam_krb5)

Accepted pam into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Hi Steve,

I've played around with this a bit, and it seems to work as intended. The only odd result I was able to get was with the following sequence of actions:

1. Enable the "krb5" profile.

2. Edit minimum_uid=1000 to some other value (say, 2000) in /etc/pam.d/common-*.

3. Edit minimum_uid=1000 to yet another value (say, 3000) in /usr/share/pam-configs/krb5.

4. pam-auth-update

5. Now, pam_krb5 is being passed e.g. "minimum_uid=3000 try_first_pass minimum_uid=2000".

Step #3 could be considered a foul, but it's a possibility if some PAM-module package gets updated.

On Sat, May 15, 2010 at 12:16:12AM -0000, Daniel Richard G. wrote:
> I've played around with this a bit, and it seems to work as intended.
> The only odd result I was able to get was with the following sequence of
> actions:

> 1. Enable the "krb5" profile.

> 2. Edit minimum_uid=1000 to some other value (say, 2000) in
> /etc/pam.d/common-*.

> 3. Edit minimum_uid=1000 to yet another value (say, 3000) in /usr/share
> /pam-configs/krb5.

> 4. pam-auth-update

> 5. Now, pam_krb5 is being passed e.g. "minimum_uid=3000 try_first_pass
> minimum_uid=2000".

> Step #3 could be considered a foul, but it's a possibility if some
> PAM-module package gets updated.

True, key=value options could end up being listed multiple times as a result
of such a three-way merge. However, avoiding this would require
pam-auth-update to make assumptions about the handling of such options that
may not hold true for all modules.

And assuming the last option takes precedence over earlier ones, the local
configuration change is still effective, so that seems like what we want.

Anyway, this is the existing behavior for the handling of all other modules,
so I don't think this impacts the SRU validation. I've also installed
libpam-runtime from lucid-proposed and haven't seen any regressions, so IMHO
this should be considered verification-done.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Oh, I agree. The three-way-merge scenario is just a curveball I wanted to throw at this since you described the feature :-) As far as I'm concerned, the fix is golden.

This bug was fixed in the package pam - 1.1.1-2ubuntu3

---------------
pam (1.1.1-2ubuntu3) lucid-proposed; urgency=low

  * pam-auth-update: fix a bug in our handling of module options when the
    module name contains digits, caused by a buggy regexp. LP: #579826.
 -- Steve Langasek <email address hidden> Thu, 13 May 2010 10:30:12 +0200