Ludovic Courtès, le Mon 16 Sep 2013 12:34:37 +0200, a écrit : > Samuel Thibault <samuel.thiba...@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. > (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. Samuel
