lkml.org 
[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: RFC [patch 13/34] PID Virtualization Define new task_pid api
From
Date
Herbert Poetzl <herbert@13thfloor.at> writes:

> well, yes, but wouldn't that be the RightThing(tm)
> anway? because 'referencing' something via a pid, then
> letting the task holding the pid go away and even be
> replaced by a new one (with the same pid) which then
> will get suddenly signaled from somewhere, just because
> the pid matches seems very broken to me ...

Agreed, but that describes the current state of the kernel.

Using a task_struct for referencing kernel threads where there
is tight collaboration seems sane. However using a task_struct
is impossible when referring to process groups, and it feels
like a bad idea to reference user space processes.

Basically my concern is that by using task structs internally
the kernel will start collecting invisible zombies. And
with a case like struct fown_struct we could force RLIMIT_NOFILE task
structs into memory, per hostile process. Usually this is much more
than RLIMIT_NPROC which limits the total number of live processes
and zombies a single user may create.

So assuming RLIMIT_NPROC == 100 and RLIMIT_NOFILE == 1024

Which means something like 100*1024*sizeof(struct task_struct) bytes
sizeof(struct task_struct) is somewhere between 512 and 1K bytes,
on a 32bit platform.

So 100*1024*512 to 100*1024*1024 = 50 to 100MB.
Being able to pin 100MB with modest ulimits does not sound like an
obvious fix to me.

Given what a hostile user can potentially accomplish I think anything that
approaches using struct task_struct pointers as a replacements for pids
should be approached carefully.

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-27 10:09    [W:0.157 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site