Reserve N process to root
Subsystems (3)
PATCH 1/1 Reserve N process to root
I think it's necessary to reserve some pids to the super user. 5 must be sufficient.
--- kernel/fork.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
kernel/fork.c +6 -1
@@ -1367,11 +1367,17 @@ long do_fork(unsigned long clone_flags,int __user *parent_tidptr, int __user *child_tidptr) { +#define RESERVED_PIDS 5 + struct task_struct *p;int trace =0 ;struct pid *pid =alloc_pid ();long nr; + if (!capable(CAP_SYS_ADMIN) && nr_threads >= max_threads - RESERVED_PIDS) { +return -EAGAIN ; + } +if (!pid)return -EAGAIN ;
nr = pid->nr;
Signature · 1 line
Gustavo Chaín Dumit
Quoted 2 lines · Gustavo Chain
I think it's necessary to reserve some pids to the super user. 5 must be sufficient.
Why? (Sorry if I missed something.)
Shouldn't you test for error return before the pid is allocated? Otherwise, I think, you have to free it. Thus:
Quoted 9 lines
long do_fork(unsigned long
clone_flags,
int__user*parent_tidptr,
int__user*child_tidptr)
{kernel/fork.c +4
-0+#define RESERVED_PIDS 5/* danged if I know why */ + +if (!capable (CAP_SYS_ADMIN ) && nr_threads >= max_threads -RESERVED_PIDS ) +return -EAGAIN ;
kernel/fork.c long do_fork(unsigned long clone_flags,
Quoted 10 lines
kernel/fork.c +1
-0+struct task_struct *p;int trace =0 ;struct pid *pid =alloc_pid ();long nr;if (!pid)return -EAGAIN ; nr = pid->nr;
(While I'm being picky, I don't like braces around a simple return, and neither, I note, does the style guide.)
Quoted 5 lines · El Wed, 10 Oct 2007 11:19:27 +0930 David Newall <[email protected]>…
Quoted 2 lines · Gustavo Chain
I think it's necessary to reserve some pids to the super user. 5 must be sufficient.
Why? (Sorry if I missed something.)
To prevent a posible DoS ?
Quoted 31 lines
Shouldn't you test for error return before the pid is allocated? Otherwise, I think, you have to free it. Thus:
Quoted 10 lines
long do_fork(unsigned long
clone_flags,
int__user*parent_tidptr,
int__user*child_tidptr)
{(quoted diff) +3
-0+#define RESERVED_PIDS 5 /* danged if I know why */ + + if (!capable(CAP_SYS_ADMIN) && nr_threads >= max_threads -
RESERVED_PIDS)kernel/fork.c +1
-0+return -EAGAIN ;kernel/fork.c long do_fork(unsigned long clone_flags,
Quoted 10 lines
kernel/fork.c +1
-0+struct task_struct *p;int trace =0 ;struct pid *pid =alloc_pid ();long nr;if (!pid)return -EAGAIN ; nr = pid->nr;(While I'm being picky, I don't like braces around a simple return, and neither, I note, does the style guide.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 1 line
Gustavo Chaín Dumit
Quoted 5 lines · Gustavo Chain
Quoted 2 lines · El Wed, 10 Oct 2007 11:19:27 +0930 David Newall <[email protected]>…
Gustavo Chain wrote:
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I think it's necessary to reserve some pids to the super user. 5 must be sufficient.
Why? (Sorry if I missed something.)
¿ To prevent a posible DoS ?
That was what I thought you had in mind; it protects from some kind of fork bomb, right? But it doesn't seem useful unless you guarantee having a process already running (with CAP_SYS_ADMIN) *before* the bomb goes off.
Quoted 12 lines · El Wed, 10 Oct 2007 15:14:06 +0930 David Newall <[email protected]>…
Quoted 11 lines · Gustavo Chain
Quoted 7 lines · El Wed, 10 Oct 2007 11:19:27 +0930 David Newall <[email protected]>…
Quoted 3 lines · Gustavo Chain
I think it's necessary to reserve some pids to the super user. 5 must be sufficient.
Why? (Sorry if I missed something.)
Quoted 7 lines
Quoted 2 lines
¿ To prevent a posible DoS ?
That was what I thought you had in mind; it protects from some kind of fork bomb, right? But it doesn't seem useful unless you guarantee having a process already running (with
CAP_SYS_ADMIN) *before* the bomb goes off.
Not really, because fork bomb will never reach maximum pid possible. And root will always have a "slot" to kill desired processes.
Signature · 1 line
Gustavo Chaín Dumit
Quoted 22 lines · Gustavo Chain
Quoted 19 lines · El Wed, 10 Oct 2007 15:14:06 +0930 David Newall <[email protected]>…
Quoted 17 lines · Gustavo Chain
Quoted 10 lines · El Wed, 10 Oct 2007 11:19:27 +0930 David Newall <[email protected]>…
Quoted 4 lines · Gustavo Chain
I think it's necessary to reserve some pids to the super user. 5 must be sufficient.
Why? (Sorry if I missed something.)
¿ To prevent a posible DoS ?
Quoted 8 lines
Quoted 4 lines
That was what I thought you had in mind; it protects from some kind
of fork bomb, right? But it doesn't seem useful unless you guarantee having a process already running (withCAP_SYS_ADMIN) *before* the bomb goes off.Not really, because fork bomb will never reach maximum pid possible. And root will always have a "slot" to kill desired processes.
This is like pulling teeth: painful.
I don't think you have satisfactorily explained why it's necessary. "To prevent a possible DoS" isn't sufficient by itself. I think you should explain the scenarios you have in mind.
Quoted 9 lines · Gustavo Chain
Quoted 4 lines · El Wed, 10 Oct 2007 15:14:06 +0930 David Newall <[email protected]>…
That was what I thought you had in mind; it protects from some kind of fork bomb, right? But it doesn't seem useful unless you guarantee having a process already running (with
CAP_SYS_ADMIN) *before* the bomb goes off.Not really, because fork bomb will never reach maximum pid possible. And root will always have a "slot" to kill desired processes.
What David meant was that "root will always have a slot" doesn't *actually* help unless you *also* have a way to actually *spawn* such a process. In order to do the ps, kill, and so on that you need to recover, you need to already have either a root shell available, or a way to *get* a root shell that doesn't rely on a non-root process (so /bin/su doesn't help here).
Many distros will leave a /sbin/mingetty running on tty1 through tty6, and you *can* use those to get a root shell. David's point is that without something like that already in place, the patch doesn't help....
Quoted 21 lines · Gustavo Chain
Quoted 9 lines
Quoted 4 lines · El Wed, 10 Oct 2007 15:14:06 +0930 David Newall <[email protected]>…
That was what I thought you had in mind; it protects from some kind of fork bomb, right? But it doesn't seem useful unless you guarantee having a process already running (with
CAP_SYS_ADMIN) *before* the bomb goes off.Not really, because fork bomb will never reach maximum pid possible. And root will always have a "slot" to kill desired processes.
What David meant was that "root will always have a slot" doesn't *actually*
help unless you *also* have a way to actually *spawn* such a process. In order
to do the ps, kill, and so on that you need to recover, you need to already
have either a root shell available, or a way to *get* a root shell that doesn't
rely on a non-root process (so/bin/sudoesn't help here).
Quoted 5 lines
Many distros will leave a
/sbin/mingettyrunning on tty1 through tty6, and you *can* use those to get a root shell. David's point is that without something like that already in place, the patch doesn't help....
but once you are logged in, how can you "spawn" processes (ps, kill, and so on) if the limit is reached ?
Quoted 5 lines · [email protected] wrote:
What David meant was that "root will always have a slot" doesn't *actually* help unless you *also* have a way to actually *spawn* such a process. In order to do the ps, kill, and so on that you need to recover, you need to already have either a root shell available, or a way to *get* a root shell that doesn't rely on a non-root process (so
/bin/sudoesn't help here).
That's right, although it's worse than that. You need to have a process with CAP_SYS_ADMIN. If root processes normally have that capability then the reserved slots may well disappear before you notice a problem. If root processes normally don't have it, then you need to guarantee that one is already running.