Re: CPU time limit patch / setrlimit(RLIMIT_CPU, 0) cheat fix

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 17 Apr 2007 16:57:55 +0300 Tom Alsberg <alsbergt@cs.huji.ac.il> wrote:

> Hi there.
> 
> As discovered here today, the change in Kernel 2.6.17 intended to
> inhibit users from setting RLIMIT_CPU to 0 (as that is equivalent to
> unlimited) by "cheating" and setting it to 1 in such a case, does not
> make a difference, as the check is done in the wrong place (too late),
> and only applies to the profiling code.

hm, I tested that.  I guess I must have only tested the profiling limit.

> On all systems I checked running kernels above 2.6.17, no matter what
> the hard and soft CPU time limits were before, a user could escape
> them by issuing in the shell (sh/bash/zsh) "ulimit -t 0", and then the
> user's process was not ever killed.
> 
> Attached is a trivial patch to fix that.  Simply moving the check to a
> slightly earlier location (specifically, before the line that actually
> assigns the limit - *old_rlim = new_rlim), does the trick.
> 
> Do note that at least the zsh (but not ash, dash, or bash) shell has
> the problem of "caching" the limits set by the ulimit command, so when
> running zsh the fix will not immediately be evident - after entering
> "ulimit -t 0", "ulimit -a" will show "-t: cpu time (seconds) 0", even
> though the actual limit as returned by getrlimit(...) will be 1.  It
> can be verified by opening a subshell (which will not have the values
> of the parent shell in cache) and checking in it, or just by running a
> CPU intensive command like "echo '65536^1048576' | bc" and verifying
> that it dumps core after one second.
> 
> Regardless of whether that is a misfeature in the shell, perhaps it
> would be better to return -EINVAL from setrlimit in such a case
> instead of cheating and setting to 1, as that does not really reflect
> the actual state of the process anymore.  I do not however know what
> the ground for that decision was in the original 2.6.17 change, and
> whether there would be any "backward" compatibility issues, so I
> preferred not to touch that right now.

The 2.6.17 changes was done that way allegedly for 2.4 compatibility.