Re: Task destruction

[Wolfgang Jährling]

Niels Möller <address@hidden> wrote:
> Wolfgang Jährling <address@hidden> writes:
> > Except for that we want more something like an association
> > <master's-task-id,task-id>, where the master is permitted to kill the
> > task "task-id", I agree.
> 
> I think it makes sense to require that what you call the "master" is a
> process. This way, we can associate the task with some user
> identities, namely the ones of the master, and use that to determine
> who may kill the task.

I don't think the task-server should know anything about the concept of
processes at all, as we want it to be possible to implement a completely
different kind of task-management.  This is the reason why I am aiming
at very primitive basic operations.

> > I have not given it too much thought, but my idea was to add an
> > argument to the task_create RPC to specify the master.
> 
> Following Roland's plan, I think it makes more sense to have a new
> task inherit the "master process" from the task that created it. That
> should be the default behaviour, only overridable by the proc server.

Does "the proc server" refer to the systems main proc server?  If not,
how do you find out who is a proc server and who isn't?

> > The task-server would notify this "master" about creation and
> > death of the task.
> 
> I think such notifications (in particular death notifications) are
> important, but other tasks need to be able to ask for notifications
> too, for no-senders notifications to work. Perhaps it's simplest to
> allow any task to register for death notifications for *any* other
> task in the system.

Yes, as long as this is not a security problem (and I don't see a reason
why it should be), this is the best thing to do.

> > When creating a new task, we would usually specify our own proc server
> > as the "master" (i.e. the task we will get from getproc (), which I just
> > assume we will, as an object handle alone is never enough).
> 
> Now it sounds like the proc server will need to know about every task.

That the systems main proc server knows about every task was my
intention.  This is also what we currently have on Mach.  I never
thought about whether this is actually good.

> I think the problem is that if both you and I create some tasks that
> in turn create some tasks that don't register with proc, I should be
> able to kill my tasks but not yours. And it seems natural to put the
> per-task book-keeping in the task server rather than in proc.

I agree that this is a problem.  An even bigger problem is that a task
could escape from the control of the user who started it.  I will think
about it.

> The two ends of the scale are:
> 
> A. The proc server knows only tasks that has registered
>    with it voluntarily. Information about other tasks must be somebody
>    else's responsibility (e.g. the task server's).
> 
> B. All tasks are known to some proc server. In this case, we could
>    assign a pid to each and every task in the system. Then there's
>    very little left to do for the task server.

I feel that B is more like what we want, because we should try to keep
functionality outside of the task-server, as users can't easiely replace
it.

> > Care to explain why you think it makes sense to treat T similar to a
> > thread in P?
> 
> Like a thread, a task has no hurd:ish or unix:ish attributes (e.g. a
> uid) by itself. And when looking at access control issues (like who is
> allowed to terminate execution or attach a debugger), basing those
> decisions on the properties of an associated process seems like a
> solution that will be easy to use and understand.

Actually I find that quite complicated, but that's just me. :-)

> > And what we do in the case of P dieing early could be left up to the
> > proc server, where I would prefer the default value not to be
> > killing.
> 
> On the other hand, "kill pid" may be a convenient way to kill a
> process and any non-process tasks it has spawn.

I'd rather say it would be a convenient way to kill a single task, as I
assume tasks will usually be independent, so why kill them all together?

> But one could have two different SIGKILL signals, one that kills the
> process and its tasks, and a different one that puts the process in
> the near-death state.

Sounds reasonable.

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling  <address@hidden>  \\  http://stdio.cjb.net/
Debian GNU/Hurd user && Debian GNU/Linux user \\  http://www.gnu.org/
The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/
["We're way ahead of you here. The Hurd has always been on the    ]
[ cutting edge of not being good for anything." -- Roland McGrath ]