> > > Hardcoding things signifying special treatment of uid=0 is almost always a
> > > bad idea. If you _really_ think that superuser (whatever entity that might
> > > be) should be exempt from RLIMIT_NPROC and can prove that (SuSv2 seems to
> > > be silent so you may be right), then you should us
On Thu, 30 Nov 2000, Pavel Machek wrote:
> Hi!
>
> > > On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > > > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000
> > > > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > > > @@ -560,7 +560,8 @@
> > > > *p = *current;
> > > >
> > > >
Hi!
> > On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > > --- linux/kernel/fork.c~ Tue Sep 5 23:48:59 2000
> > > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > > @@ -560,7 +560,8 @@
> > > *p = *current;
> > >
> > > retval = -EAGAIN;
> > > - if (atomic_read(&p->user->processes) >= p
On Tue, 28 Nov 2000, Alan Cox wrote:
> > Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j=
> > ob to
> > prevent admin from shooting him/her self in the foot.
> >
> > root should be able to do fork() regardless of any limits,
> > and IMHO the following patch is the right t
In article <[EMAIL PROTECTED]>,
Frank v Waveren <[EMAIL PROTECTED]> wrote:
>On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote:
>> > Because you want to be able to `kill `?
>> > And if you are over-limits you can't?
>> Wrong. limit is a shell built in
>
>I assume you mean kill is a shell bu
On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote:
> > Because you want to be able to `kill `?
> > And if you are over-limits you can't?
> Wrong. limit is a shell built in
I assume you mean kill is a shell builtin. Depending on your shell. :-).
It's still a real pain when you want to get t
> > AFAICS, _all_ resource limits are equally applied to root processes. =
> Why
> > should NPROC be different?
>
> Because you want to be able to `kill `?
> And if you are over-limits you can't?
Wrong. limit is a shell built in
-
To unsubscribe from this list: send the line "unsubscribe linux
> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j=
> ob to
> prevent admin from shooting him/her self in the foot.
>
> root should be able to do fork() regardless of any limits,
> and IMHO the following patch is the right thing.
This patch is bogus. root can always raise
On Tue, 28 Nov 2000, Andreas Schwab wrote:
> Jan Rekorajski <[EMAIL PROTECTED]> writes:
>
> |> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
> |> prevent admin from shooting him/her self in the foot.
> |>
> |> root should be able to do fork() regardless of any lim
Jan Rekorajski <[EMAIL PROTECTED]> writes:
|> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
|> prevent admin from shooting him/her self in the foot.
|>
|> root should be able to do fork() regardless of any limits,
|> and IMHO the following patch is the right thing.
On Tue, 28 Nov 2000, Tigran Aivazian wrote:
> On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000
> > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > @@ -560,7 +560,8 @@
> > *p = *current;
> >
> > retval = -EAGAIN;
> > - if (ato
Jan R_korajski writes:
> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
> prevent admin from shooting him/her self in the foot.
> - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
By default, root has no real process limits anyways, so th
> On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000
> > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > @@ -560,7 +560,8 @@
> > *p = *current;
> >
> > retval = -EAGAIN;
> > - if (atomic_read(&p->user->processes) >= p->rlim[RLIM
On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> --- linux/kernel/fork.c~ Tue Sep 5 23:48:59 2000
> +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> @@ -560,7 +560,8 @@
> *p = *current;
>
> retval = -EAGAIN;
> - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPR
Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
prevent admin from shooting him/her self in the foot.
root should be able to do fork() regardless of any limits,
and IMHO the following patch is the right thing.
--- linux/kernel/fork.c~Tue Sep 5 23:48:59 200
15 matches
Mail list logo