Re: PATCH: proc_do_stop and rpctrace

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 comparisons
> between ports from the user (rpctrace) and ports outside rpctrace's sphere
> of interposition.  I bet "rpctrace ln foo bar" (dir_link) gets EXDEV too.

Actually, according to some helpful soul (hi Jeroen), it works just fine.
Which makes sense, because the port for foo and whatever else comes from the
filesystem, and rpctrace rewrites it in both directions, first when it comes
in.

The problem is with ports that are rewritten the first time when the come
out, but are actually ports that come from the outside and have never been
seen by rpctrace before.  The task and thread ports come to mind, because
they are gotten by system calls in the task.

The only way to properly fix it seems to somehow provide the task with
a replacement task port to be used instead of mach_task_self, which requires
support in the task (ie glibc).  Which would mean all RPCs, even
mach_task_deallocate etc, would go through rpctrace (not really a performance
boost :).  The other way to fix it would be to allow the task to keep task
and thread related RPCs to itself, and then always keep the task and thread
ports in rpctrace (problem: we won't be notified of new threads) to be able
to prevent translations of these 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/