Re: ports suggestion

[Richard Wesley Todd]

Thanks for your comments.

On 12 Dec 2000, Niels Mvller wrote:
> Caching information sounds tricky to get right, but perhaps it can be
> done (I haven't tried to think hard about it).

It may be tricky (tuning the hash function and size for decent performance).
But once it's right, I think it would be excellent for cutting down on 
unnecessary IPC calls.  For most servers, the internal table wouldn't need
to be large at all to accomodate the traffic it'll see.  

The only thing is making sure the cached data is
not out-of-date.  Thus the need to check the thread timestamp, and
complications for setuid stuff (see below).  

The only thing to really recommend this idea is the assumption that 
one could ask for the thread's age _much_ faster than a roundtrip IPC 
to proc server and back.  If they are just as costly, just query proc 
(or auth, or whatever) every time you need to check.

> 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?
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.'   It seems like, at best, port rights restrict
a process to a subset of the user's rights.  In that case, I again
ask: How does the OS know which rights to grant and which not?

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

I've considered this, but wanted to get the basic idea out before
I muddied the waters.  If the server gets an indication that the
calling thread is able to change uids, it will know to trust the
cached information less, and track the altered or unaltered state
of the process.  This causes more IPC to proc, but 
keeps things safe and secure.  It's a rough suggestion -- Better ideas
are very welcome.

For setuid processes:
1) Cached data indicates unaltered uid has no access, so the library
knows to query the proc server in case it has changed it's uid/gid.
2) Cached data indicates unaltered uid has access.  No need to check
the proc server since they could've changed uid but it doesn't matter
(assumes processes always setuid _up_ in access rights from their 
 starting point).
3) Cached data indicates altered uid has access, so the library knows
to query the proc server in case it has dropped back to normal.
4) Cached data indicates altered uid has no access, so the library 
knows not to bother checking the proc server.  (not valid if the
    process can change to multiple iuds...can it?)

Thanks again,

Richard Todd