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 protected] [email protected] -- pam-auth-update loses user-specified module options if the module name has a digit in it (pam_krb5) https://bugs.launchpad.net/bugs/579826 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
