Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Eric W. Biederman]

Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/