Re: thread ids, task ids and subsystems

[Niels Möller]

Maurizio Boriani <address@hidden> writes:

> I'had few idea after afternoon (post eat) "otium":
>         * task server could route rpc from a task to another one in totally
>                 free and leave decision to accept or deny request to 
>                 destination task. So task server will act like a router in 
>                 an ip network: route all and the destination should protect
>                 himself.

Putting access control onto the task in question is a nice idea. If I
understand you correctly, a task A will only talk to the task server
to make changes to itself (say, comitting suicide, or creating a new
thread). To manipulate a different task B, A should talk to B, not to
the task server.

However, there's one problem: You want to be able to give task A the
right till kill task B at some later time, even if task B won't
cooperate. To do this, one needs to talk to the task server and
convince it that one is allowed to kill B. Which is what task ports
and port rights is about.

> So could be needed an auth server (or acl server) which dispatch and verify
> credentials like a simplified krb and store policies.

I think the current plan for handling ports and port rights is that
each resource will manage the information needed to keep track of who
is allowed to access the resource. There's no need for any central
server for this (the hurd auth server will still be needed, but it
doesn't have anything to do with the per message rpc access control
we're talking about now).

/Niels