aboutsummaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorTom Alsberg <alsbergt@cs.huji.ac.il>2007-05-08 03:30:31 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 14:15:12 -0400
commit9926e4c74300c4b31dee007298c6475d33369df0 (patch)
treec2251d7f6a19874de8388b4271d6b2b9836cae38 /kernel
parenta4bb27d99ca2986e30180a0eb143865051b909db (diff)
CPU time limit patch / setrlimit(RLIMIT_CPU, 0) cheat fix
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. 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. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel')
-rw-r--r--kernel/sys.c19
1 files changed, 10 insertions, 9 deletions
diff --git a/kernel/sys.c b/kernel/sys.c
index fe1f3ab20477..926bf9d7ac45 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1923,6 +1923,16 @@ asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit __user *rlim)
1923 if (retval) 1923 if (retval)
1924 return retval; 1924 return retval;
1925 1925
1926 if (resource == RLIMIT_CPU && new_rlim.rlim_cur == 0) {
1927 /*
1928 * The caller is asking for an immediate RLIMIT_CPU
1929 * expiry. But we use the zero value to mean "it was
1930 * never set". So let's cheat and make it one second
1931 * instead
1932 */
1933 new_rlim.rlim_cur = 1;
1934 }
1935
1926 task_lock(current->group_leader); 1936 task_lock(current->group_leader);
1927 *old_rlim = new_rlim; 1937 *old_rlim = new_rlim;
1928 task_unlock(current->group_leader); 1938 task_unlock(current->group_leader);
@@ -1944,15 +1954,6 @@ asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit __user *rlim)
1944 unsigned long rlim_cur = new_rlim.rlim_cur; 1954 unsigned long rlim_cur = new_rlim.rlim_cur;
1945 cputime_t cputime; 1955 cputime_t cputime;
1946 1956
1947 if (rlim_cur == 0) {
1948 /*
1949 * The caller is asking for an immediate RLIMIT_CPU
1950 * expiry. But we use the zero value to mean "it was
1951 * never set". So let's cheat and make it one second
1952 * instead
1953 */
1954 rlim_cur = 1;
1955 }
1956 cputime = secs_to_cputime(rlim_cur); 1957 cputime = secs_to_cputime(rlim_cur);
1957 read_lock(&tasklist_lock); 1958 read_lock(&tasklist_lock);
1958 spin_lock_irq(&current->sighand->siglock); 1959 spin_lock_irq(&current->sighand->siglock);