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/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 ;-)
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.
If this solution is good enough, I'm willing to implement it and test it.
Regards -- Ognyan Kulev <[EMAIL PROTECTED],fsa-bg.org}> 7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782
_______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
