[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ports suggestion
From: |
Richard Wesley Todd |
Subject: |
ports suggestion |
Date: |
Sat, 9 Dec 2000 22:22:29 -0600 (CST) |
First let me say I'm new to Mach, L4, and the Hurd, so if this is
way off please forgive my ignorance. The list seems dead and I
hope this at least starts up the conversation again.
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.'
First, the generic scenario (suggestion follows):
1) Thread 21 from task 3 sends an IPC to some server 'A'.
L4 fills in the source id itself, so there can be no
forgery.
2) Server 'A' calls a library routine to authenticate the
connection.
3) This routine finds the effective UID and GID of the
caller, and returns it to A. (more on this later)
4) Server 'A' decides whether or not to fail the request.
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.
- When asked to authenticate a connection, it checks the
hash table. If it finds the caller, it asks L4 when that
thread was created. A timestamp older than our information
means it's still good. This takes care of id wrapping.
- If the cached info is too old, or we don't have the
caller's information in the table, it sends IPC to
proc asking for the UID info (we must be able to
trust proc--is that a problem?).
Does this make sense? Let me fill out my earlier example:
3a) Server 'A' calls the libports routine to authenticate this
IPC.
3b) The routine cannot find the id in it's hash table, so it
sends an IPC to proc to get the info. This is stored in
the hash table, along with the current time.
3c) Server 'A' decides this is an ok connection, and handles the
request.
Later, if the same thread sends another message....
3a) Server 'A' calls the libports routine to authenticate.
3b) The routine finds the UID in the hash table, and queries
L4 for the timestamp of the caller's task/thread. The
thread has been up since before our saved timestamp, so
we don't need an IPC to proc. We just return the
hashed authentication.
This strikes me as an efficient, secure way of doing port-like
message handling. What do you think? I'm sure there are holes
in it but I thought I'd jump in and contribute to the list.
As for querying L4 for the timestamp, it unfortunately doesn't
fall under lthread_ex_regs, since that only gives info for
threads in the current task. In the name of efficiency, I'd
suggest either extending lthread_ex_regs, or adding an eighth
system call. (I know that won't be popular, but we are trying
to facilitate the most fundamental act the Hurd performs...and
the alternative is more IPC messages.)
Sincerely,
Richard Todd
address@hidden
- ports suggestion,
Richard Wesley Todd <=