[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The auth interface on L4-Hurd

From: Marcus Brinkmann
Subject: Re: The auth interface on L4-Hurd
Date: Thu, 1 Aug 2002 22:59:20 +0200
User-agent: Mutt/1.4i

On Thu, Aug 01, 2002 at 10:52:39PM +0200, Wolfgang Jährling wrote:
> Wolfgang Jährling <address@hidden> wrote:
> > b) The auth server could try to verify that the handle he got from the
> >    server is something that refers to the user, but as handles can, like
> >    ports, be passed around, this does not work.
> I think I was wrong here.  But what we _will_ need is an RPC from auth
> to the user to make sure the handle we got from the server is ok.

Exactly.  Before we can talk about how auth should work, we must talk about
how the primitive operation that auth requires works, and that is moving a
handle from client A to client B.  You seem to think that moving a handle is
just passing a number in a message.  This won't work for several reasons,
the moving-a-handle protocol must be more complex, and it is not fully
worked out yet.

When we know how moving a handle works, we can take another look at auth.
I think that moving a handle should give you the guarantee that if you
have two handles for the same object, you can be sure that they are the
same, no matter which way they took in the system.  If this holds, then I
think what I said is correct.

This can be established by having the recipient of the handle talk to the
object designated by it, to find out if it really is a valid handle, and by
having the server only having one handle per task for each object.  These
constraints should pretty closely define what possible protocol you have to
go through to move a handle.  It is not without problems, though (Neal
pointed out possible races where a handle might get lost in transit if the
sender dies too soon).

> But, do we maybe have a race condition here?  When the server has made
> the RPC to the user to move his handle to auth, but before he does the
> auth_server_authenticate, someone else might make the
> auth_server_authenticate for him, guessing the correct handle number.  How
> can this be prevented?

You must never simply trust a number you get from somewhere.  This is
obvious.  The server must tell the user (which is the server of the
rendevouz port) that it is moving the right to the auth server.  Then later
on, the auth server must verify that it really got the right handle from the
server.  Something like that, we have not worked out the details.  Maybe you
want to look into this issue more closely?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]