Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager

2016-09-05 Thread Samuel Thibault
Samuel Thibault, on Wed 31 Aug 2016 17:59:02 +0200, wrote:
> Debian is uploading 2.24, so we need to implement something now.

2.24-2 is now uploaded.

Samuel



Re: RFC: Revised authentication protocol

2016-09-05 Thread Richard Braun
On Sun, Sep 04, 2016 at 10:29:54PM -1000, Brent W. Baccala wrote:
> For those of you who have followed my netmsg threads, you may remember that
> there were two major issues when I first got it running.  One was
> libpager's lack of multi-client support, which has been discussed at
> length, and the other was authentication, which we haven't discussed at all.

Well, not exactly. I think I've mentioned Plan9's factotum at some
point, which I'll remind again in this message as a reference we can
draw from.

> Here's my proposal for dealing with the authentication issue.
> 
> Comments?

I'm not completely familiar with the inner workings of the auth
server but they look easy enough to imagine. Still, an opinion
from someone more familiar with it like Olaf would be great.

>From what I've read, it looks good. I can't imagine a scenario that
would defeat your assertions.

-- 
Richard Braun



RFC: Revised authentication protocol

2016-09-05 Thread Brent W. Baccala
Aloha -

For those of you who have followed my netmsg threads, you may remember that
there were two major issues when I first got it running.  One was
libpager's lack of multi-client support, which has been discussed at
length, and the other was authentication, which we haven't discussed at all.

Here's my proposal for dealing with the authentication issue.

There should be an extra send right passed from the auth server, to the
client, that the client then passes along to the server in its
authentication request, and that the server then passes on to the auth
server in its auth_server_authenticate messsage.  This is distinct from the
auth_object.  Unlike the auth_object, this right conveys no credentials and
is used primarily to identify the auth server.  Let's call it the
auth_identifier.

In the present scheme, you can see that the auth_identifier gets passed
around in a big circle.  When the auth server gets the
auth_server_authenticate message from the server, it sees that it's gotten
its own auth_identifier back, and things proceed as they do now.

The more interesting case is when the auth_identifier differs.  That
happens when we're dealing with two different auth servers on different
hosts.

First, the auth_identifier allows the auth server to detect this case.

Next, it provides a means for the two auth servers to complete the
rendezvous.  The server's auth server can pass the rendezvous right to the
client's auth server using the auth_identifier.

There's no way for the server's auth server to fool the client's auth
server into thinking that this is a normal server authentication request,
because the only communication between the two is via the auth_identifier.
The client's auth server can clearly distinguish messages coming in over
this port from auth_server_authenticate messages, which would come directly
from a server over a different port.

Finally, the auth servers can use the auth_identifier to speak any kind of
inter-auth-server protocol that they wish.  At the moment, the exact
details of that protocol are beyond the scope of this proposal.  I
envision, perhaps, a public key exchange.  Something that would let
mutually cooperating auth servers decide how to map UIDs/GIDs from one auth
domain to another.  I haven't thought through the details, but I think this
proposal is flexible enough to handle just about anything we'd want to do.

Comments?

agape
brent