Re: alternative: port server?

[Neal H. Walfield]

> > > > > However, in the Hurd we are more flexible.  A task can reauthenticate 
> > > > > an io
> > > > > object.  In that sense, user IDs (really: authentication tokens) are 
> > > > > bound
> > > > > to objects and not to tasks.  This is useful in many applications.
> > > > 
> > > > But for the authentication token to be valid, it is bound to a task.
> > > > Thus, to transfer an authentication token, it is renamed.
> > > 
> > > Nope, an authentication token is an object in the task server and denoted 
> > > by
> > > the task server id and the object id.
> > 
> > Not in the Hurd on L4.
> 
> Argh.  I meant auth server.  If that is not what you mean, then you have to
> explain the alternative.

My point is the following: an authentication token is a "port" known
to the authentication server.  In Mach, ports are controlled by Mach
(and the authentication server only worries about port rights).  When
a task wants to transfer an authentication token to another server, it
cannot simply copy the port right's number: the port right's number
only has meaning in the task of which the port right is a part;
instead, it has to transfer the port right in a message.  When Mach
receives the message, it "renames" the enclosed port right making it
valid in the target task.  This is similar in L4, however, every
server is a port server.  Thus when I send a message to the
authentication server and include a "port," it is only able to prove
its authenticity by knowing the senders task id (the only provable
piece of information we have) and then looking the port up in the
sender task's port table.  This is why "ports" on L4 cannot be faked.
Thus, authentication tokens are bound to a task and not an object
insofar as ports are bound to a task.