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

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

On Wed, Jul 11, 2012 at 01:03:32PM -0400, J. Bruce Fields wrote:
> On Tue, Jul 10, 2012 at 10:58:40PM +0000, Myklebust, Trond wrote:
> > All the documentation in the patches was appearing to imply that it
> > affected only nfsd with filenames such as
> > "Documentation/filesystems/nfs/knfsd-rpcgss.txt".and patch changelogs
> > with titles such as "SUNRPC: Use gssproxy upcall for nfsd's RPCGSS
> > authentication."
> 
> Fixed locally (and pushed out temporarily to for-3.6-incoming branch at
> git://linux-nfs.org/~bfields/linux-topics.git).  Thanks for catching
> that.
> 
> > > > > How will it behave if I don't run gss proxy?
> > > 
> > > It will work, but if the server's running on the same machine it will
> > > also use svcgssd, and hence won't (for example) be able to handle the
> > > larger init_sec_context packets.
> > 
> > An NFS client callback server is only trying to check that it is talking
> > to a machine credential with a name of the form nfs@hostname. It doesn't
> > care about PAGs, and anyone who tries to set the machine cred up with
> > one is clearly insane anyway...
> 
> Yes.  I don't know enough to say that a larger init_sec_context call
> could never be required for some other reason--but it sounds unlikely.
> 
> Anyway: I was hoping that the old upcall mechanism could be declared a
> legacy thing--no new features, bugfixes only for regressions, etc.--and
> possibly be removed after a long transition period.
> 
> If it's a requirement that the client never use the gssproxy mechanism,
> even on the 4.0 backchannel, then that requires committing to develop
> both.  I don't think that makes sense.

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.

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.

--b.