Re: Hacking gnumach to track parental relationship of tasks

[Ludovic Courtès]

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?  :-)

>> (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].

Ludo’.

[0] http://www.gnu.org/software/hurd/hurd-paper.html