Re: Limits broken in 2.4.x kernel.

Andrew Morton
2001-12-18T00:00:05Z

Trond Myklebust wrote:
>
> >>>>> " " == war <war@starband.net> writes:
>
> > Problem: Per-user process limits to not work correctly with a
> > 2.4.x kernel.
>
> > Say I want to limit a user to [5] processes.
>
> > Example: Edit [/etc/security/limits.conf]
> > user hard nproc 5 -or- @group hard nproc 5
>
> > The result: The user cannot login.
>
> > How to fix?
>
> One thing I noticed when doing the BSD cred patch for 2.5.x is that
> somebody broke the process accounting in 2.[45].x at least for the
> case of reparent_to_init():

That would be me.

> If you just charge current->user without moving over the process from
> the old uid to the new uid (such as is done in kernel/sys.c with the
> set_user() routine) then you risk seriously corrupting the counters.
>
> I'm not sure really what the point was of setting the user in
> reparent_to_init() in the first place, since it doesn't setreuid().

reparent_to_init() is there to cope with various strange things
which occur when a kernel thread is parented by a userspace process.
It's called after daemonize(), so the thread can no longer participate
in filesystem related things.

I think what you've pointed out here is yet another problem with
the idea of having kernel threads parented by user processes: they
articificially increase the user's process count.

I didn't have a clear reason for moving the UID to root's - it just
didn't seem a good idea to have kernel threads running with non-root
UIDs. But we have a reason now - process accounting.

reparent_to_init() needs to decrement current->user's processes count,
and increment root's. I'll do a patch.

-