On Apr 8, 2014, at 14:24, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Tue, 8 Apr 2014 14:03:04 -0400 > Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > >> >> On Apr 8, 2014, at 13:55, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> >> As far as I can tell, the downcall can be extended. Even the security context is an opaque, so its length is known. If we wanted to append a field after that, we could do so without affecting backward compatibility. >> > > Yeah, I think you're right. It looks like gss_pipe_downcall will just > ignore stuff that trails the security context. I'll have a look at > see whether tacking a new field on is feasible. > > So in nfs4_proc_setclientid after the call, we can add some code that > copies the new acceptor field out of gss_cred->gss_cl_ctx, and attaches > it to a new field in the nfs_client. Alternately, I wonder if we could > get away with just replacing the clp->cl_hostname with that value? I don’t think we want to replace clp->cl_hostname. If someone wants to play around with the ‘-p’ option in rpc.svcgssd, then we may end up with some rather strange hostnames on the client... _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
