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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2012-07-10 at 18:12 -0400, Trond Myklebust wrote:
> On Tue, 2012-07-10 at 17:56 -0400, J. Bruce Fields wrote:
> > On Tue, Jul 10, 2012 at 09:52:51PM +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.
> > 
> > The rpc server's authentication method is global to the machine, so if
> > the NFS server is using gss proxy, then I believe the callback server
> > will be as well.
> 
> Then why is it being labelled as a knfsd-only change?
> How will it behave if I don't run gss proxy?

...and how will it behave in a net namespace?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com

��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux