diff options
author | Eric W. Biederman <ebiederm@xmission.com> | 2006-03-31 02:31:33 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-31 12:18:59 -0800 |
commit | 390e2ff07712468ce6600a43aa91e897b056ce12 (patch) | |
tree | fb92d3c2218fa3e41078d1b5e103892ac7e95117 /kernel/fork.c | |
parent | 9741ef964dc8bfeb6520825df9fed8f538c3336e (diff) | |
download | lwn-390e2ff07712468ce6600a43aa91e897b056ce12.tar.gz lwn-390e2ff07712468ce6600a43aa91e897b056ce12.zip |
[PATCH] Make setsid() more robust
The core problem: setsid fails if it is called by init. The effect in 2.6.16
and the earlier kernels that have this problem is that if you do a "ps -j 1 or
ps -ej 1" you will see that init and several of it's children have process
group and session == 0. Instead of process group == session == 1. Despite
init calling setsid.
The reason it fails is that daemonize calls set_special_pids(1,1) on kernel
threads that are launched before /sbin/init is called.
The only remaining effect in that current->signal->leader == 0 for init
instead of 1. And the setsid call fails. No one has noticed because
/sbin/init does not check the return value of setsid.
In 2.4 where we don't have the pidhash table, and daemonize doesn't exist
setsid actually works for init.
I care a lot about pid == 1 not being a special case that we leave broken,
because of the container/jail work that I am doing.
- Carefully allow init (pid == 1) to call setsid despite the kernel using
its session.
- Use find_task_by_pid instead of find_pid because find_pid taking a
pidtype is going away.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'kernel/fork.c')
0 files changed, 0 insertions, 0 deletions