Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[ebiederm@xmission.com (Eric W. Biederman)]

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/