[Bug 391761] Re: process limit unlimited (regression)

[Steve Langasek]

Fixed in oneiric with the merge of pam 1.1.2-3.  Changelog:

pam (1.1.2-3) unstable; urgency=low

  [ Kees Cook ]
  * 027_pam_limits_better_init_allow_explicit_root: load rlimit defaults
    from the kernel (via /proc/1/limits), instead of continuing to hardcode
    the settings internally. Fall back to internal defaults when the kernel
    rlimits are not found.  Closes: #620302. (LP: #746655, #391761)

  * Updated debconf translations:
    - Vietnamese, thanks to Clytie Siddall <clytie at riverland.net.au>
      (closes: #601197)
    - Dutch, thanks to Eric Spreen <erispre at gmail.com> (closes: #605592)
    - Danish, thanks to Joe Dalton <joedalton2 at yahoo.dk> (closes: #606739)
    - Catalan, thanks to Innocent De Marchi <tangram.peces at gmail.com>
      (closes: #622786)


** Changed in: pam (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/391761

Title:
  process limit unlimited (regression)

Status in “pam” package in Ubuntu:
  Fix Released

Bug description:
  AFAIK, RLIMIT_NPROC is determined by the kernel based on available
  physical memory.  In my 512M VMs, I see the following results of
  "ulimit -u":

  dapper: unlimited
  hardy, intrepid: 4095
  jaunty, karmic: unlimited

  The intention is to have this set to in an attempt to reasonably
  mitigate fork-bombs without getting in the way of intentionally big
  process collections.  Jaunty and Karmic appear to have regressed.  I
  am assuming this is a PAM bug, but it may be a kernel issue.  Tracking
  RLIMIT setting has always eluded me.  :)