Re: thread ids, task ids and subsystems

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> Now, you might say that proc gets a special accounting id that is privileged
> (the root accounting id if you want), but then you still have to tell me how
> accounting ids are given (are they per user?), and how you want to implement
> "go via proc".

Well, proc probably has to be "privileged" is some way, e.g. the
*first* task calling some special task rpc would be considered
privileged by task, or it can be setup in some other way during
bootstrap.

Accounting id:s are assigned when a task registers with proc. As part
of the registration, proc sends the set_accounting_id rpc to task, to
set accounting_id = pid.

In the simplest case, where a task only has *one* accounting id, these
are the only accounting id:s, and they're all set by proc.

A generalization which I think I described some months ago is to have
several accounting id:s. Any task A can register an accounting id, say
17, for task B, and then task will associate the pair <A, 17> with B,
where the first element is the owner of the id. Only the owner of an
accounting id is allowed to change it.

As above, proc will register pairs <proc, pid> with any task that
registers with proc, and it won't care for about accounting id's set
by other tasks. Say you run boot to start a sub hurd. If the boot
process has pid 7, and a process in the subhurd has pid 17 (registered
with the proc server in the subhurd), then that task will have the
following accounting ids:

  <proc, 7>, <subproc, 17>.

To kill it, one either have to tell the subhurd proc server till kill
process 17, or tell the parent proc server to kill process 7. The
latter will kill the boot process and all tasks in the subhurd,
because they have all inherited the <proc, 7> id, and they don't have
permission to change that.

> You would need to have a thread_control call and a
> proc_thread_control, and so on for all calls where you might have to
> "go via proc". Any way I approached this it ended up with silly
> constructs like that.

I was thinking of something like that. I agree that using real task
ports seems like a less silly way of doing access control.

/Niels