Re: Hacking gnumach to track parental relationship of tasks

[Ludovic Courtès]

Justus Winter <4winter@informatik.uni-hamburg.de> skribis:

> 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/

Thanks.

Seems that cgroupfs works in terms of PIDs, so at the POSIX level.
There could be Mach tasks that are not Hurd processes, and thus evade
cgroupfs too.

I understand this is undesirable here.

However, wouldn’t it be preferable to fix it by interposing on
‘task_create’ calls, à la clans & chiefs?  (IIUC, this can be done with
by setting the TASK_KERNEL_PORT of a task.)

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

OK.

Ludo’.