Hey again,
On Tue, Apr 05, 2011 at 02:35:43AM -0700, Steve Langasek wrote:
Hi Thorsten,
> > (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?
Hmm, no answer to this question... does that mean everyone's still thinking
it over, or just totally horrified by the idea?
For reference, here's the original Debian bug report that led to this patch
being carried. Unfortunately I don't think it was ever forwarded upstream
at the time.
http://bugs.debian.org/63230
Thanks,
--
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