Description of problem: David Peer has reported the following problem in the kernel handling of "ulimit" function: <cite> Hi, I'm using zsh 4.3.2-25 on debian, and noticed that when any user run: ulimit -t 0 from its shell, he manages to disable the cputime limitation if any. for example: I have a debian system that has cpu time limitation of 1 minute soft, and 2 minutes hard. If the user run: ulimit -t 0, he can run jobs without any cputime limitation: You can see the output from "top" command, that it ran the job "testload" for more then 6 minutes. Thanks in advanced, David Peer. </cite>
Comment to Micah Cowan to this issue: David Peer wrote: > > If the user run: ulimit -t 0, he can run jobs without any cputime > > limitation: This sounds more like a kernel problem to me than a zsh bug. I get the same behavior on my Ubuntu 7.04 (beta) system, in _bash_. I note that getrlimit(2) says: In 2.6.x kernels before 2.6.17, a RLIMIT_CPU limit of 0 is wrongly treated as "no limit" (like RLIM_INFINITY). Since kernel 2.6.17, set‐ ting a limit of 0 does have an effect, but is actually treated as a limit of 1 second. However, I'm running 2.6.20(-14-generic), and still experiencing that symptom.
Another Tom reaction: I checked the problem earlier today (by reference of David who pointed it out to me - thanks, David). The problem is apparently in the Linux kernel, where the check for trying to set RLIMIT_CPU = 0 is done a bit too late, and has nothing to do with zsh. Specifically, the same symptoms were visible with other shells (ash, bash) too. I checked the Linux kernel sources and found the solution in kernel/sys.c. Attached is a copy of my message with the patch to the Linux-Kernel Mailing List. One issue that may be relevant within zsh, though, is that it appears that zsh caches the limits set, and since that check in Linux "cheats" by setting the value to 1 when 0 is requested, entering "ulimit -a" does not call getrlimit(...) at all and does show 0 after issuing the command "ulimit -t 0", although getrlimit(RLIMIT_CPU, ...) would return 1. The correct limit is seen in a subshell where this is not yet cached. I expect my patch to be in the next Linux 2.6.21 release candidate. Cheers, -- Tom
Proposed upstream patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9926e4c74300c4b31dee007298c6475d33369df0
Link with more detailed information: http://marc.info/?l=oss-security&m=120527771109026&w=4
This was addressed via: Red Hat Enterprise Linux version 5 (RHSA-2008:0612)