Messages in this thread | | | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api | From | (Eric W. Biederman) | Date | Fri, 27 Jan 2006 02:04:21 -0700 |
| |
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/
| |