On Tue, 8 Apr 2014 14:45:03 -0400 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > 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... > Ok, fair enough. A new field it is... -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
