Re: RFC: Revised authentication protocol

[Brent W. Baccala]

On Mon, Sep 19, 2016 at 9:52 AM, Olaf Buddenhagen 
wrote:

> I'm a bit confused here: my understanding was that you essentially
> wanted to implement a "single system instance" cluster. I would have
> thought that would imply only a single instance of most servers --
> including auth -- rather than separate ones for each node?...
>

Well, I'm starting with a network transport for Mach messages that should
be usable for remote filesystem and remote process execution.  I've thought
a little bit about how to reconfigure the boot process to use centralized
auth and proc servers, but only a little bit.  Right now, I'm trying to
achieve one of the goals on the translator wish list: "network file system
by just forwarding RPCs

"

Also, as Richard noted, it might be best to use distributed processes.  A
cluster filesystem, for example, might be implemented a bit like unionfs,
with the local filesystems on each node underlying a global filesystem.
The global filesystem could be implemented by a group of processes, one per
node.  A process's file objects would generally be handled by the global
filesystem's local process, which would use the underlying local filesystem
for replicated files, cached files, locally created files, etc., and only
hand off to remote nodes for files unavailable on the local filesystem.

I see your point, though.  It would be ironic to modify the auth protocol
only to end up with a cluster using a single auth server.

agape
brent

Re: RFC: Revised authentication protocol

[Richard Braun]

On Mon, Sep 19, 2016 at 09:52:38PM +0200, Olaf Buddenhagen wrote:
> I'm a bit confused here: my understanding was that you essentially
> wanted to implement a "single system instance" cluster. I would have
> thought that would imply only a single instance of most servers --
> including auth -- rather than separate ones for each node?...

I would think it best to make that a distributed process.

-- 
Richard Braun

Re: RFC: Revised authentication protocol

[Samuel Thibault]

Olaf Buddenhagen, on Mon 19 Sep 2016 21:52:38 +0200, wrote:
> Note that for the container solutions (lightweight virtualisation) I'm
> envisioning for the Hurd -- with things like sub-users -- we are likely
> to need some kind of auth delegation scheme or something like that;

Well, AIUI we already have that: the bootstrap translators
(auth/proc/rootfs) are known to the host auth/proc. Others aren't, but
that's fine since they talk with the bootstrap translators, and thus
their requests go through them, to eventually reach the host auth/proc.

Samuel

Re: RFC: Revised authentication protocol

[Olaf Buddenhagen]

Hi,

On Sun, Sep 04, 2016 at 10:29:54PM -1000, Brent W. Baccala wrote:

> 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.

I'm a bit confused here: my understanding was that you essentially
wanted to implement a "single system instance" cluster. I would have
thought that would imply only a single instance of most servers --
including auth -- rather than separate ones for each node?...

Note that for the container solutions (lightweight virtualisation) I'm
envisioning for the Hurd -- with things like sub-users -- we are likely
to need some kind of auth delegation scheme or something like that; but
I haven't spent too much thought on this. Not sure whether it would be
relevant to your work in any way...

On Mon, Sep 05, 2016 at 02:09:56PM +0200, Richard Braun wrote:

> 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.

I'm not really very familiar with the details of the auth protocol. The
stuff I discussed extensively with Carl at some point (as a solution to
the infamous "firmlink issue") was more about handling of the ID sets
obtained through the auth mechanism -- I don't think it involved changes
to the auth protocol itself... Not sure though. Maybe Carl remembers
better than me?

-antrik-

Re: RFC: Revised authentication protocol

[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