GSSAPI Proxy initiative

[Trond Myklebust]

On Thu, 2011-11-03 at 13:57 -0500, Nico Williams wrote: 
> On Thu, Nov 3, 2011 at 11:31 AM, Simo Sorce <simo at redhat.com> wrote:
> > On Thu, 2011-11-03 at 11:05 -0500, Nico Williams wrote:
> >> If the proxy daemon process dies, how should the proxy client recover?
> >
> > Either wait for the proxy to restart or treat it as an unrecoverable
> > error, just like if the network goes away ?
> 
> If state is lost the client has to recover.  Sure, it's going to
> somehow (perhaps by returning an error to the user, who then retries).
>  Point is: a stateless (or stateless + caching, for perf) design would
> avoid this.
> 
> For the protocol that just means that handles need to be opaque octet
> strings, NOT just small integers.  Whether a given implementation is
> stateless is another story.  This is what I was driving at.
> 
> > Ok, I can see how this may help.
> 
> :)
> 
> >> There's no complication.  The protocol needs to allow for
> >> arbitrary-sized object handles -- that's all.
> >
> > Ok, I was complaining about making the server more complicated, but
> > that's probably not really true, we will just trade one set of issues
> > with another as the state is kept 'somewhere' anyway, so I retire my
> > concern.
> 
> Right.
> 
> >> I'd much rather not have to pass anything, but we need to support OSes
> >> where that's just how it's done.  I'd rather that IPC end-points can
> >> find out what what they need about their peers.  Think
> >> door_ucred(3DOOR).
> >
> > I don't think I want to use the PID and then try to pull out environment
> > variables through /proc or similar interface, that would be bad.
> 
> I would never have suggested that.
> 
> What I had in mind was something like PAGs or keyrings.  Or, to be
> much more specific, search for my name and the string "credentials
> process groups" -- a PAG on steroids.
> 
> The idea is that the IPC peer can observe the other's
> PAG/keyring/CPG/whatever and use that to find the correct credentials
> (authorization is still required though).

Linux already has per-user, per-process and per-thread keyrings which
offer a high security storage solution for keys. The problem with those
is that they are difficult to use in an asynchronous context when the
original user's process/thread context is no longer available to us.

Ideally, though, that's what we'd like to see used.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust at netapp.com
www.netapp.com