On Tue, 2012-07-10 at 18:38 -0400, J. Bruce Fields wrote:
> On Tue, Jul 10, 2012 at 10:25:13PM +0000, Myklebust, Trond wrote:
> > On Tue, 2012-07-10 at 18:12 -0400, Trond Myklebust wrote:
> > > Then why is it being labelled as a knfsd-only change?
>
> It should be labeled an rpc server change.
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."
> > > 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...
> > ...and how will it behave in a net namespace?
>
> It will need the same fixes as we need for rpcbind.
So basically, it will have to store the path at client creation time?
> I'm sure we could allow the callback server and the nfs server to use
> different authentication upcalls. But that makes this not worth it.
The point is that in a containerised environment, the NFS client may not
know what protocol that an NFS server running in a completely different
container is using.
> We should be able to share the same use the same mechanism on all rpc
> servers, so if a mechanism based on gssproxy calls isn't acceptable for
> the nfs callback server then I'll drop it.
I don't see how you can enforce that premise when using containers.
--
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�����٥
