GSSAPI Proxy initiative

Trond Myklebust Trond.Myklebust at
Thu Nov 3 16:39:44 EDT 2011

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> 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 Myklebust
Linux NFS client maintainer

Trond.Myklebust at

More information about the krbdev mailing list