Re: [PATCH 0/4] Add support for new RPCSEC_GSS upcall mechanism for nfsd

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Jul 12, 2012 at 06:10:58PM -0400, J. Bruce Fields wrote:
> On Wed, Jul 11, 2012 at 05:49:09PM +0000, Myklebust, Trond wrote:
> > On Wed, 2012-07-11 at 13:27 -0400, J. Bruce Fields wrote:
> > > So, if the issue is: you want to be able to choose, in individual
> > > containers, which mechanism to use: whatever, we can probably make that
> > > work.
> > 
> > Please do then.
> > 
> > > If you're instead saying: it's not acceptable to use the gssproxy
> > > mechanism to authenticate v4.0 callbacks, the client must only ever use
> > > the existing mechanism: then I'd rather drop this entirely.  I don't
> > > want to merge an rpc server authentication upcall that's not acceptable
> > > for one of the rpc servers.
> > 
> > If it goes in, I want it to be optional so that it doesn't break working
> > setups. I also want upgrades/downgrades to be as painless as possible. 
> > 
> > See for instance the idmapper changes in 3.5 which are totally
> > transparent to the user: if the admin sets up /etc/request-key.conf to
> > use the new id_resolver, then that works, otherwise we just fall back to
> > using the old rpc.idmapd method. There are no module parameters etc
> > involved.
> 
> There's a module parameter here, but it's meant to be set by gssproxy to
> indicate it's listening for the new upcall.  In theory that should make
> the transition transparent.
> 
> However, if we need to make the choice per-namespace then we need to
> find some other mechanism (assuming there's no way to make module
> parameters per-namespace.)

So, perhaps something like: if the cache "channel" file for the
namespace associated with the current request isn't opened, then try the
new upcall.

--b.