Re: PATCH: proc_do_stop and rpctrace

[Marcus Brinkmann]

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 retrieves microkernel's task list and searches for this 
> particular task.  So user can't promote his own port as task port to the 
> proc server.  So what I said is plain wrong, and just propaganda ;-)

Ah, good.  I stopped dead at the add_task and didn't bother to look up what
it does ;)
 
> One possible solution is rpctrace not to masquarade system ports, like 
> thread ports, and the patch to be reverted.  For example, on each traced 
> mach_msg, the list of task's threads can be retrieved.  This will allow 
> not masquarading thread ports when they are passed through mach_msg.  It 
> will slow the whole tracing, but at least it will circumvent this 
> particular problem.

This is one option I just sent in a mail to hurd-devel.  The other option
which is slightly cleaner is to provide the task with a wrapped task and
thread port, and in consequence also wrap other thread ports, and have
support in glibc that it uses these ports instead mach_task_self and
mach_thread_self.  Which is also a performance hit, because now RPC trace
gets to see almost all RPCs, including those on local ports.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/