On Tue, Apr 05, Steve Langasek wrote:
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?
You should ask big ISVs, especially database vendors, why they
are doing this.
But in short: Some resources depending on memory, diskspace, and
processors are calculated dynamically depending on your hardware,
others are fix values coming from the config file.
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.
Because you don't know what the defaults are and who did set them for
which reason.
On openSUSE/SLES we have the ulimits package, which sets global, default
limits for all processes based on a config file and available hardware
through the init process.
This patch by default enabled would reset the limits to something
surprising. And worse, not for everything, but only for this, who
are called by a process which did run pam_limits before.
> 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.
Correct.
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?)
What is the clean state in this case? How do you know who did set
the limit and for which reason? And what should be the correct one?
Thorsten
--
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)