Hi,
On Tue, Aug 19, 2003 at 09:53:07PM -0400, Etienne Robillard wrote:
on implementing the auth module (currently running on mach_port_t and all) in idl4 grammar with L4 ipc/syscalls. Question is how the relationship between mach_port_t would affect l4_threadid_t and folks ?
I am currently in the business of writing a capability system for the Hurd that will replace mach ports and is written in user land (decentralised - local in each task) on L4.
The following is not currently appropriate for any of the Hurd/Mach RPC device or L4 syscalls:
module auth { /* this is the generic auth module implementation for Hurd */ interface auth_getids /* generic api for _ids */ { int l4_ids_t([out] static l4_threadid_t ids_t, [out] &idarray_t /* some foo here je je */); };
There is nothing L4 specific about IDs, so you would use uid_t and gid_t for them. As you must be aware, the Hurd has four type of ID arrays, effective/available and user/group. So what this interface must look like is this:
interface passport { /* Validate the passport PASSPORT and return the IDs of the user it belongs to if successful. Every auth object is also a passport object. */ error_t passport_validate (in passport_t passport, out uid_t euids[], out uid_t auids[], out gid_t egids[], out gid_t agids[]); }
Note that I am introducing a new object passport that is sort of a "read-only" auth object and can be used for authentication (the current authentication scheme in the Hurd is asynchronous and thus subject to DoS attacks, and we will change it). The corresponding calls to manipulate auth handles are:
interface auth { /* Create a new auth object with the specified IDs. The new auth object can only contain a subset of (or exactly) the IDs that are contained in the auth objects AUTH and OTHERS, unless one of the user ID lists in these objects contains a 0. Then arbitrary objects can be created. */ error_t auth_new (in auth_t auth, in auth_t others[], in uid_t euids[], in uid_t auids[], in gid_t egids[], in gid_t agids[], out auth_t new_auth);
/* Get a passport that can be used by other parties to verify the IDs contained in the auth object AUTH. */ error_t auth_get_passport (in auth_t auth, passport_t passport); }
Note that This is only a partial implementation of the auth.def interface - but since the module is so small; it may be easier to port with l4_* components.
The auth server will require GLibC, just as any other task except the rootserver (which will not provide any service except wrapping the privileged system calls). The main thing auth will need from GLibC is the capability system to provide the above auth_t and passport_t capabilities. The capability system will hide all the details about creating capabilities, making them available to users, monitoring user connections and exchanging capabilities between user tasks.
One problem with the above interface is that because it is using dynamic length arrays, IDL4 will compile it using string items. But using string items requires extra carefulness in the client, as it must not page fault during the transfer (the server must use a zero timeout to prevent DoS attacks) - see the paper that was discussed on the list recently about IPC security. In auth, this is not so much of a problem: Creating or reading an auth handle has no side effects, so any failed IPC can just be retried. However, that this is the case must somehow be tagged in the IDL file and understood by the IDL compiler or RPC wrapper in GLibC.
Thanks, Marcus