Hi Thorsten,
On Tue, Apr 05, 2011 at 10:28:47AM +0200, Thorsten Kukuk wrote:
> On Fri, Apr 01, 2011 at 08:47:19AM +0200, Tomas Mraz wrote:
> > On Thu, 2011-03-31 at 15:16 -0700, Kees Cook wrote:
> > > Since the kernel sets a number of dynamic rlimits based on the system
> > > properties (e.g. physical memory for nproc), these rlimits should be
> > > respected by PAM. Parse /proc/1/limits for the kernel-defined rlimits.
> > Please provide a better rationale for the patch. The
pam_limits module
> > will not change any limits that are not set in the configuration file.
> > And for the limits that are set there, the value in the configuration
> > file should be respected. If I understand your patch correctly, you
> > basically want to reset the limit to the values set on the init process.
> > This definitely should not be a default behavior.
> This patch provides the lowest level of default. The
configuration files
> will always override them if the config is present.
> The primary reason for doing this is that when PAM runs, it may
not have a
> sensible set of default rlimits, so it should always start over from the
> kernel-defined defaults.
That would be a wrong behavior of pam_limits. If an application sets
limits and then forks, pam_limits shouldn't reset that values.
Can you give an example of why an application would do this and then open a
PAM session for which it calls pam_limits, if it expects these limits to be
retained?
I understand that the status quo is that the upstream pam_limits doesn't do
that, and so it would come as a surprise if pam_limits started resetting
limits; but I don't see any reason why, from the POV of application design
or distro packaging, it would make sense for an application that cared about
setting limits to by default then turn around and let pam_limits change
these settings.
> (Some distros, at least Debian and Ubuntu, have
> worked around this in the past by using hard-coded defaults, but this is
> suboptimal in the face of dynamic rlimits set by the kernel based on
> memory/cpu/etc.)
> Additionally, this allows PAM running in containers to adjust
automatically
> to what is set as the rlimit defaults for the "init" running in a given
> container namespace.
I have to admit that I still don't understand the problem.
But we use a package "ulimits" to set global, usefull limits
during boot time. Afterwards the init scripts/processes can
overwrite them for their needs.
The original patch that Kees's work is based on was added to the Debian
package by Ben Collins some years ago to address the issue that when
changing from one user to another with 'su', the limits configured from the
original user would be retained unless explicitly overridden in limits.conf.
I think it's pretty unambiguously correct to reset the limits to a clean
slate in this case (why would you want su to a user to give different
limits, based on the identity of the login user, than a direct login?), but
it's difficult to separate this case out from those cases where you say the
limits should *not* be reset.
Have you guys solved this issue some other way?
Cheers,
--
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/
slangasek(a)ubuntu.com vorlon(a)debian.org