Re: Task destruction

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> > Agree, except that I suspect that we'd need a *list* of handles to
> > support multiple proc servers in a natural way.
> 
> I (almost) don't think so.  Every process will only register itself with one
> proc server.  That proc server can install a new handle in the task
> inheritance tree if useful for it and if it is a privileged task.

This thread started with the question of task destruction. I imagine
the handles being used for this: To kill a task, you must be the
target of one of the task's control handles (exactly how this check
will be done I don't know, it looks like a bidirectional reference
while a handle seems more unidirectional). That is usually a proc
server, which is happy to kill tasks on the behalf of processes with
the right uid or other privileges.

If you use the handles only for tracking, that might be ok, but then
you need some other mechanism to termine who can control (e.g. kill)
the tasks.

> For the unprivileged Hurd systems, that means it can not install new
> handles, and all tasks in that system will get the same handle as the boot
> process' task got.  So root can easily track those systems.

But then the proc server in the child hurd can neither track nor
control its proceses, which makes the child hurd pretty useless. When
running in the child hurd, I want different users to be able to kill
their own, but not eachother's, tasks, and that means that the child
hurd's proc server must be in control of the tasks. And of course, the
parent hurd's proc server should also be in control. That's why having
the possibility of several control handles seems essential.

I realize that you could probably get around that with a proxy task
server, but I think it would be cleaner and simpler to let both hurds
use the same task server (and the same memory server for that matter),
unless there's a really good reason that can't work.

/Niels