Re: Hacking gnumach to track parental relationship of tasks

[Justus Winter]

Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-07 14:37:03)
> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
> 
> > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-06 11:58:43)
> >> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
> >> 
> >> > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-05 18:11:43)
> >> >> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
> >> >> 
> >> >> > I made two rather small and (as I thought) straight forward changes to
> >> >> > gnumach to keep track of a tasks father task and to make this
> >> >> > information available.
> >> >> 
> >> >> Isn’t that what ‘proc_getpids’ is for?
> >> 
> >> [...]
> >> 
> >> > And here lies the problem, this is a mere convention. Until a process
> >> > is reparented using proc_child its parent is pid 1. Currently it is
> >> > possible to start tasks (and thus 'processes') without marking them as
> >> > ones child. This is a problem for a robust cgroups implementation.
> >> 
> >> Thanks for explaining, that’s the part I was missing.
> >> 
> >> However, I’m not sure what problem this is solving (but I miss the
> >> bigger picture of your project, apologies for that.)  The convention you
> >> describe is always honored for POSIX programs, since ‘fork’ always calls
> >> ‘proc_child’.  And non-POSIX programs are outside of the scope, I
> >> suppose, no?
> >
> > If any program can evade the cgroup mechanism by using task_create
> > there is no point to implement cgroupfs.
> 
> Sorry, I’ve never head of cgroupfs; any pointers?

https://teythoon.cryptobitch.de/posts/cgroupfs-keeps-track-of-processes/

I forgot to mention this in our discussion, I have high hopes that
tracking this relation in the kernel also allows me to start subhurds
as non-root user: https://savannah.gnu.org/bugs/?17341

I want the "root" proc server to interface with the kernel and any
subhurd proc server to request notifications about new tasks from the
root proc server. This way it doesn't need the host-priv ports to talk
to the kernel.

But in order to figure out which tasks to hand out to a subhurd proc
server the root proc server (or any one in between) needs to know
which newly created task belongs to this subhurd b/c handing out the
wrong tasks breaches the process isolation.

The way it works now is that any proc server has to run as root and
gets all the task ports from the kernel, so any root user inside the
subhurd can get hold of any task/process of any other proc server,
which is clearly undesireable.

Justus