Re: ports suggestion

[Niels Möller]

Richard Wesley Todd <address@hidden> writes:

> It seems like the biggest problem going to L4 is that Mach's
> fundamental communication channel is a port, and L4 has no
> such thing.  Here's an idea that I _think_ gives us most things 
> we really need from a 'port.'

You're right, we either need ports, or something different that
provides the features of ports we need.

> Obviously, the hard part is (3).  Here is my suggestion:
> We have a library (think of it as libports if you like) that
> that:
>   - Keeps an internal hash table of task/thread id's, their
>     UIDs, and the timestamp when it got the information.

Caching information sounds tricky to get right, but perhaps it can be
done (I haven't tried to think hard about it).

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. It means that if you give one user process a right to
talk to you, as a side-effect, any process with the same uid gets that
right. But perhaps that's not a big problem, as we don't have any
hard security boundaries between processes run by the same user.

One also have to figure out how this is going to work for processes
with several uids, and processes that change uid.

Say I give a send right to a process running as user A. Then I'm
giving that right to any process run by A (as explained above). Assume
that the process changes uid to B. Then it will either lose the send
right, or we are extending it to all processes run by B. If the
process changes back to A after a while, will processes run by B still
own the send right, or there anyway it can be revoked automatically?
Does this matter, or should we simply accept that uid changes causes
diffusion of rights?

For ordinary fd:s, the answer seems to be not to care.

/Niels