<div dir="ltr">I'm sending to lustre-devel for wider distribution/comment.<div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jeremy Filizetti</b> <span dir="ltr"><<a href="mailto:jeremy.filizetti@gmail.com">jeremy.filizetti@gmail.com</a>></span><br>Date: Mon, Mar 23, 2015 at 9:34 PM<br>Subject: proposed version change for PTLRPC GSS<br>To: "<a href="mailto:iudev@lists.opensfs.org">iudev@lists.opensfs.org</a>" <<a href="mailto:iudev@lists.opensfs.org">iudev@lists.opensfs.org</a>><br><br><br><div dir="ltr">On the phone call last week we discussed an increment of the PTLRPC_GSS_VERSION to version 2 to allow some changes changes/restructuring.  No one had any objections on the phone call but I wanted to send it out for wider distribution and feedback.<div><br></div><div>Changing the request format would allow us to support larger GSS token sizes which today are limited (see ticket LU-3855).   From what I have looked through so far the following seems to allow for larger tokens and also allow some of these changes without having to worry about backwards compatibility since it was never really "working" anyways.</div><div><br></div><div>Change PTLRPC_GSS_VERSION to 2</div><div><br></div><div>Enlarge GSS_CTX_INIT_MAX_LEN to something larger then 1024.   Ideally we would support MaxTokenSize of 64k for the largest active directory ticket: (see <a href="http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx" target="_blank">http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx</a>).</div><div>The purpose of enlarging this is to support larger tokens.  The sizeof(struct rsi) needs to remain under PAGE_SIZE right now with rsi_request calling sunrpc_cache_pipe_upcall.  Since there is only one lsvcgssd process supposed to be running maybe it would be acceptable to use larger requests and just slightly modify rsi_request to incorporate must of the functionality of sunrpc_cache_pipe_upcall.</div><div><br></div><div>To keep things simple with the lsvcgssd and continue to use a single channel proc file interface I'd like to AND the GSS subflavor onto most significant bits of lustre_svc in struct rsi.  Instead of calling the inappropriately named handle_nullreq things would be changed to handle the multiple subflavors (gssnull, sk, krb5).  gssnull and sk won't have a full userspace component so gss_accept_sec_context can't be called.</div><div><br></div><div>Thoughts welcome.  I'm sure I missed something along the way here but this is just what I have looked at so far.</div><div><br></div><div>Thanks,</div><div>Jeremy</div></div>
</div><br></div></div>