[17375] in Kerberos_V5_Development
Re: GSSAPI Proxy initiative
daemon@ATHENA.MIT.EDU (Trond Myklebust)
Thu Nov 3 16:59:53 2011
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Nico Williams <nico@cryptonector.com>
Date: Thu, 03 Nov 2011 16:39:44 -0400
In-Reply-To: <CAK3OfOjj0GOPpeEBi4kA9jqP-vfgYqYMdv1P44H3ve0gU0hg5g@mail.gmail.com>
Message-ID: <1320352784.18396.109.camel@lade.trondhjem.org>
Mime-Version: 1.0
Cc: dhowells <dhowells@redhat.com>, linux-nfs@vger.kernel.org,
love@pch.mit.edu, Simo Sorce <simo@redhat.com>,
krbdev <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, 2011-11-03 at 13:57 -0500, Nico Williams wrote:
> On Thu, Nov 3, 2011 at 11:31 AM, Simo Sorce <simo@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@netapp.com
www.netapp.com
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
