UVFe: PAM 0.99

[Kees Cook]

I've got PAM 0.99 merged, and I'd like to get it into Gutsy.

Merge is here[1], including the debdiffs between Debian for the old[2] and the new[3] versions. The Debian changelog[4] is extensive, but is probably worth us getting it into Gutsy to get as much shake-down time as we can.

It would fix at least these bugs: 43169 14505 80431

By dropping the ~/.pam_environment patch, it would fix: 113586

Changes to the ulimit defaults would more closely match those of other distros.

From initial testing (default desktop install, my insano weird desktop, and server ldap), it seems to be working without problems.

[1] http://people.ubuntu.com/~kees/gutsy/
[2] http://people.ubuntu.com/~kees/gutsy/pam_0.79-4ubuntu2.ubuntu.diff
[3] http://people.ubuntu.com/~kees/gutsy/pam_0.99.7.1-4ubuntu1.ubuntu.diff
[4] http://packages.debian.org/changelogs/pool/main/p/pam/current/changelog

[Jonathan Riddell (jr)]

This seems like a good idea but I think it deserves more testing than you describe, could you put .debs somewhere (or build in a PPA) and ask ubuntu-server people to test it?

[Kees Cook (kees)]

Agreed; I have uploaded to PPA: https://launchpad.net/~keescook/+archive

Also, for reference, some discussion on ubuntu-devel:
https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024213.html

[Soren Hansen (soren)]

it works like a charm for me on my server with both opie and otpw, which I guess is fairly exotic. :)

[Martin Pitt (pitti)]

I tested the following things on current gutsy amd64 with the PPA packages:

 * Upgrade
 * libpam-foreground functionality
 * cups web UI (uses PAM)
 * passwd changing
 * passwd locking and unlocking
 * chfn

Those were successful.

I also highly appreciate the fixing of the default ulimits. However, there seems to be a hitch (maybe amd64 specific?):

$ ulimit -i -u
pending signals (-i) 24575
max user processes (-u) 24575

Isn't this supposed to be 2048?

[Kees Cook (kees)]

That is very weird. Yeah, I see the same on my amd64 too. I will
investigate.

[Kees Cook (kees)]

This value is based on available system memory and is expected to change: http://tinyurl.com/24jq6l

[Martin Pitt (pitti)]

Ah, I see. Then it does seem to work fine, although I question the sensibility of determining nproc from RAM.

[Kees Cook (kees)]

I actually think it is more correct that a static fixed value (and significantly more correct than "unlimited").

Regardless, it sounds like this has gotten a fair bit of testing now; shall I upload it to the main repository, or should we wait a while longer? Maybe I should ask "What are next steps?"

[Martin Pitt (pitti)]

I agree. Please go ahead and upload.

[Kees Cook (kees)]

Uploaded, thanks!