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. Given that, the containerization issues seem irrelevant, but: > > > ...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 think that's right. > > 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. I don't believe there's a requirement that containers be able to use different upcall mechanisms. Are we allowing people to choose between new and old client idmappers per container? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
