Andrew Morton <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
