Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-07 14:37:03) >> Justus Winter <4win...@informatik.uni-hamburg.de> skribis: >> >> > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-06 11:58:43) >> >> Justus Winter <4win...@informatik.uni-hamburg.de> skribis: >> >> >> >> > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-05 18:11:43) >> >> >> Justus Winter <4win...@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’.
