On Mon, Apr 04, Kees Cook 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.
(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.
Thorsten
--
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Markus Rex, HRB 16746 (AG Nuernberg)