On Sat, Aug 16, 2003 at 03:58:34PM +0300, Ognyan Kulev wrote:
> This is exactly what I meant, but I haven't looked deep enough. This
> user-supplied task_t is added through proc/mgt.c:add_tasks (called from
> proc/hash.c:task_find, called from proc/mgt.c:S_proc_child). But
> add_tasks retrieve
Marcus Brinkmann wrote:
That it simply adds the task
port in proc_child might in fact mean that it uses the user supplied task
port as you indicate, but I am not sure you meant that.
This is exactly what I meant, but I haven't looked deep enough. This
user-supplied task_t is added through proc/mg
On Sat, Aug 16, 2003 at 11:16:57AM +0300, Ognyan Kulev wrote:
> proc also uses the task port given by rpctrace. So one can write a
> program that passes fake task port to proc, and when proc tries to
> handle the fake process in some way, the whole proc server will hang
> because it is single-t
> proc also uses the task port given by rpctrace. So one can write a
> program that passes fake task port to proc, and when proc tries to
> handle the fake process in some way, the whole proc server will hang
> because it is single-threaded.
a) proc is not single-threaded
b) proc does not send
Marcus Brinkmann wrote:
On Sat, Aug 09, 2003 at 05:33:29PM -0400, Roland McGrath wrote:
The concern I have about this patch per se is proc calling thread_resume on
a random port from the user. This is at least a DoS opportunity. It also
points to a more general problem rpctrace has--servers make
