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 [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
