Herbert Poetzl <[email protected]> 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 [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]
