Re: ports suggestion

[Niels Möller]

Richard Wesley Todd <address@hidden> writes:

> > If I read you correctly, you propose to map the thread id to a user
> > id, and then base access decisions on the user id. This is quite
> > different from ports, where each process a user runs owns a distinct
> > set of port rigths. 
> 
> I guess I still haven't wrapped my mind around the usefullness of 
> port rights that aren't tied directly (unix-style) to the user.  If 
> they are not, how does the OS know if a port deserves a right or not?

One can thing of a port as the interface to a resource (at least
that's the way I'm thinking). Any process with a send right to the
port can delegate it further, as it sees fit. The OS need not be
involved in making decisions on delegation.

> If my text editor wants to write to a file, what should the filesystem 
> server do?  I can't think of anything except 'see if that user has 
> appropriate access.'

That's what the filesystem does when it initially hands out a port right
for a port that represents a certain file. (And if I have understood
the auth-server mechanism correctly, that implemented  in such a way
that "being a user", in this context, is equivalent to having send
right to a certain port in the auth server). But the right can be
delegated further, without involving the filesystem server.

/Niels