Arjan van de Ven <[email protected]> writes:
>> So, like in the global pidspace (which can see all pids and appears to
>> applications to be just like normal) you end up returning "kernel" pids
>> to userspace. That didn't seem to make sense.
>
> hmm this is scary. If you don't have "unique" pids inside the kernel a
> lot of stuff will subtly break. DRM for example (which has the pid
> inside locking to track ownership and recursion), but I'm sure there's
> many many cases like that. I guess the address of the task struct is the
> ultimate unique pid in this sense.... but I suspect the way to get there
> is first make a ->user_pid field, and switch all userspace visible stuff
> to that, and then try to get rid of ->pid users one by one by
> eliminating their uses...
>
> but I'm really afraid that if you make the "fake" pid visible to normal
> kernel code, too much stuff will go bonkers and end up with an eternal
> stream of security hazards. "Magic" hurts here, and if you don't do
> magic I don't see a reason to add an abstraction which in itself doesn't
> mean anything or doesn't abstract anything....
Thanks, you said that better that I did :)
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]
