Re: Hacking gnumach to track parental relationship of tasks

[Samuel Thibault]

Ludovic Courtès, le Mon 16 Sep 2013 14:03:50 +0200, a écrit :
> Samuel Thibault <samuel.thibault@gnu.org> skribis:
> 
> > Ludovic Courtès, le Mon 16 Sep 2013 12:34:37 +0200, a écrit :
> >> Samuel Thibault <samuel.thibault@gnu.org> skribis:
> >> 
> >> > Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
> >> >> On Thu, Sep 12, 2013 at 10:38:31AM +0200, Samuel Thibault wrote:
> >> >> > Richard Braun, le Thu 12 Sep 2013 10:33:23 +0200, a écrit :
> >> >> > > Then why are we discussing interposing system calls ?
> >> >> > 
> >> >> > Because a malicious program can still use the trap to escape whatever
> >> >> > cgroup system we are setting up.
> >> >> 
> >> >> I suggest we simply disable the trap versions.
> >> >
> >> > Ah, right.
> >> >
> >> > I don't have the time to dive into the details, but in the end, couldn't
> >> > we switch to making task_create rather a proc RPC, rather than relying
> >> > on process nicely calling the proc proc_child RPC after having created
> >> > the task? proc would be doing the "kernel" task_create RPC on behalf
> >> > of the process. The main proc server would actually make a kernel RPC,
> >> > a sub-hurd proc server would nicely ask for it, thus not having to be
> >> > root.
> >> 
> >> But you’d still need a “real” task_create anyway, no?
> >
> > It'd be an RPC to te kernel from the main proc server.
> 
> That’s what it already is, no?  :-)

Yes, but there is also still the kernel trap.

> >> (I think the theory was that it should be possible to have a system
> >> where both POSIX-personality processes (known to proc) and other tasks
> >> would coexist in peace and harmony.)
> >
> > Well, we are not even talking about POSIX here, but about mere tasks,
> > which should not be allowed to float around without being assigned a
> > shepherd.
> 
> My understanding is that the design purposefully allows Mach tasks
> unknown to proc, and proc is seen as a service “to help out programs
> that *wish* to use Posix features” (emphasis mine) [0].
> 
> [0] http://www.gnu.org/software/hurd/hurd-paper.html

Well, then it can be done by something else than the proc server, it
does not really matter much.  What matters is that we don't want to let
user tasks leak tasks without some control.

Samuel