Re: auth.idl

[Marcus Brinkmann]

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

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/