Hi,
Wouldn't it make sense that somewhere in kernel/fork.c:dup_task_struct we
copy the resource limits as follows.
int i;
for (i = 0; i < RLIM_NLIMITS; i++)
tsk->rlim[i].rlim_cur =
tsk->rlim[i].rlim_max =
orig->rlim[i].rlim_cur;
This way a parent process is able to temporary drop some of its limits in
order to make a restricted child process and restore its resource limits
afterwards. Currenly it is not possible to make a child process with
smaller resource limits than the parent process without the parent process
losing its (hard) max limits (As far as I know, correct me if I'm wrong).
I could very much use this to control core dumping of child processes in
a better way. Of course I don't know to what extent this will break
things. POSIX???...couldn't find anything on it.
Please CC me.
Frank.
On Thu, Oct 24, 2002 at 02:13:01PM +0200, Frank Cornelis wrote:
> This way a parent process is able to temporary drop some of its
> limits in order to make a restricted child process and restore
> its resource limits afterwards. Currenly it is not possible to
> make a child process with smaller resource limits than the parent
> process without the parent process losing its (hard) max limits
> (As far as I know, correct me if I'm wrong).
Hmm, this statement suggests the author misunderstands the Unix-based
conventional use of the separated fork/exec calls. After the fork
call, the child process is still running code common to the parent,
but typically (by convention) a different leg of an if-then-else
statement. This code in this leg can reduce resource limits before
make an exec call to start a new program. The parent's limits are
not affected. There's no need to change the kernel.
--
Randolph Bentson
[email protected]