Re: 2.6.28, rlimits, performance and debian etch

[Steve Langasek]

On Thu, Jan 29, 2009 at 01:19:00PM +0100, Adam Tkac wrote:
> Hi all,

> I don't think the "rlim_infinity" patch should be reverted. Let me try
> to explain why.

> First, code which sets limits to RLIM_INFINITY is very bad idea and
> that code is Debian specific. I downloaded original pam 0.79 (stripped):

> for(i = 0; i < RLIM_NLIMITS; i++) {
> 	...
> 	int r = getrlimit(i, &pl->limits[i].limit);
> 	...

> as you can see original pam sets limits to inherited defaults. After
> code written above Debian adds their patch:

> if (limits_not_defined_in_limits_conf) {
> 	...
> 	case RLIMIT_NOFILE:
> 	...
> 		pl->limits[i].limit.rlim_cur = RLIM_INFINITY;
> 		pl->limits[i].limit.rlim_max = RLIM_INFINITY;
> 	...
> }

> so as you can see inherited default limits are overriden to infinity.
> In my opinion Debian should revert their patch which is, at least,
> pretty incorrect and unsecure.

It has already been mentioned that this does not apply to the upcoming
Debian 5.0 release (lenny); this patch is only present in the 4.0 release
(etch), it was actually fixed in the development series to not use
RLIM_INFINITY *because* previous kernels didn't support this and would cause
pam_limits to throw log warnings.

Nevertheless, this is not "incorrect and [in]secure."  Raising the default
limits to their maximum values in Debian's Linux-PAM is a deliberate
decision to ensure that the limits applied when su'ing from another user are
the same as when logging in directly as that user, without requiring full
specification of all limits in limits.conf for all users.  It happens to
fail in this case because the default set by the kernel for all users is
different from the maximum allowed by the kernel; but if setting NOFILE to
RLIM_INFINITY isn't a sane thing to do, why does the kernel allow it?  Note
that reverting the Debian PAM change doesn't prevent a local admin from
accidentally triggering this problem because they want to unlimit one or
more of their users.

The purpose of pam_limits is to enable admins to easily apply resource
policies, not to dictate what the set of valid policies is.  If
RLIM_INFINITY is not a sane value for RLIMIT_NOFILE, the kernel should
disallow it.

> Next argument is POSIX compatibility (from setrlimit() specification):

> "The value RLIM_INFINITY, defined in <sys/resource.h>, shall be
> considered to be larger than any other limit value. If a call to
> getrlimit() returns RLIM_INFINITY for a resource, it means the
> implementation shall not enforce limits on that resource. Specifying
> RLIM_INFINITY as any resource limit value on a successful call to
> setrlimit() shall inhibit enforcement of that resource limit."

> So kernel does what is expected. If you want "unlimited" number of
> descriptors, you have it.

This is not a POSIX compliance issue.  POSIX does not require that
setrlimit(RLIMIT_NOFILE, RLIM_INFINITY) *succeeds*; it only requires that,
*if* it succeeds, it has the described semantics.

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@xxxxxxxxxx                                     vorlon@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/