![]() | |||||||||||
Messages in this thread |
Andrew Morton <akpm@osdl.org> writes: >> 408dad0f2b7067b23929866150e73b2b2f12d662 >> diff --git a/fs/exec.c b/fs/exec.c >> index 055378d..c9d8e31 100644 >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -600,6 +600,12 @@ static int de_thread(struct task_struct >> if (thread_group_empty(current)) >> goto no_thread_group; >> >> + /* A threaded init must exec from it's primary thread. >> + * As the init task (i.e. child_reaper) may not exit. >> + */ >> + if (!thread_group_leader(current) && (current->tgid == 1)) >> + return -EINVAL; >> + >> /* >> * Kill all other threads in the thread group. >> * We must hold tasklist_lock to call zap_other_threads. > > hmm, this just looks like overhead. If sometime someone _does_ try to > thread init, what will happen to them? If it's something nice and nasty, > they'll just whine at us and stop doing that. Same net effect, no runtime > cost. So threading init will work just fine. The only case that will blow up is calling exec from something that is not the thread group leader. i.e. If tgid == 1 but pid != 1 the kernel will cause pid == 1 to exit. I think that will trigger a kernel panic. It might just ensure that no more processes are re-parented to init. And we dereference a bad pointer we look at child_reaper. I haven't been brave enough to try it. The cost is only paid if you are a threaded task and you call exec. Normal process never take that path, so we are already off of the fast path. The test when all expanded out is only: if ((current->tgid == current->pid) && (current->tgid == 1)) return -EINVAL So it should be relatively cheap. If process id namespaces become a reality init stops being terribly special, and becomes something you may have several of running at any one time. If one of those inits is compromised by a hostile user I having the whole system go down so we can avoid executing a cheap test sounds terribly wrong. That is why I really care. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-01-29 11:29 [from the cache] ©2003-2008 | |||||||||||