Messages in this thread |  | | | Subject | Re: [RFC] [PATCH 00/13] Introduce task_pid api | | From | (Eric W. Biederman) | | Date | Wed, 07 Dec 2005 12:42:06 -0700 |
Arjan van de Ven <arjan@infradead.org> 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 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/
|  |