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

[Simo Sorce <simo@redhat.com>]

On Tue, 2012-07-10 at 21:52 +0000, Myklebust, Trond wrote:
> On Tue, 2012-07-10 at 16:49 -0400, J. Bruce Fields wrote:
> > On Fri, May 25, 2012 at 06:09:52PM -0400, Simo Sorce wrote:
> > > This patchset implements a new upcall mechanism that uses the sunrpc
> > > client to talk to gssproxy[1], a new userspace daemon that handles gssapi
> > > operations on behalf of other processes on the system.
> > > 
> > > The main driver for this new mechanism is to overcome limitations with
> > > the current daemon and upcall. The current code cannot handle tickets
> > > larger than approximatively 2k and cannot handle sending back large user
> > > credential sets to the kernel.
> > > 
> > > These patches have been tested against the development version of gssproxy
> > > tagged as kernel_v0.1 in the master repo[2].
> > > 
> > > I have tested walking into mountpoints using tickets artificially pumped
> > > up to 64k and the user is properly authorized, after the accept_se_context
> > > call is performed through the new upcall mechanism and gssproxy.
> > > 
> > > The gssproxy has the potential of handling also init_sec_context calls,
> > > but at the moment the only targeted system is nfsd.
> > 
> > OK, absent objections from anyone else I'm commiting these for 3.6 and
> > pushing them out soon pending some regression testing.  Thanks!
> 
> Please test that the NFSv4 backchannel continues to work unchanged with
> the existing rpc.svcgssd before you commit.
> 
> I don't care what happens to the NFS server, but I do expect all
> existing NFSv4 client setups to work without any need for changes.

This change is optional and need to be explicitly activate by loading
the rpc_gsssec module with a parameter that enables the new method.

If you do not do that it keeps using the legacy method which uses
rpc.svcgssd

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York