[lustre-devel] [Iudev] proposed version change for PTLRPC GSS

[Sebastien Buisson]

Re-emitting because of issues with my email address.
--------

Hi,

As I understand the need for evolutions in the GSS code, I advocate the 
review and merge of all patches related to Kerberos revival as soon as 
possible. It would avoid painful rebase of work done by IU, or Kerberos 
patches, or both.
The Kerberos revival patches waiting for review are:
http://review.whamcloud.com/14040
http://review.whamcloud.com/14041
http://review.whamcloud.com/14042

Best regards,
Sebastien.


Le 25/03/2015 22:25, Dilger, Andreas a écrit :
> Sebastien,
> can you please also add lustre-devel at lists.lustre.org to the CC list for
> this discussion.
>
> On 2015/03/24, 3:12 AM, "Sebastien Buisson" <sebastien.buisson at atos.net>
> wrote:
>
>> Hi there,
>>
>> I agree we should not bother with backward compatibility. Kerberos
>> revival patches aim at Lustre 2.8, so we are good if the modifications
>> you propose also land in 2.8.
>>
>> Taking advantage of the opportunity to replace handle_nullreq with
>> subflavor specific code is really nice, as those bits are really
>> confusing for someone who tries to understand the code.
>>
>> Cheers,
>> Sebastien.
>>
>>
>> Le 24/03/2015 02:34, Jeremy Filizetti a écrit :
>>> 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.
>>>
>>> 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.
>>>
>>> Change PTLRPC_GSS_VERSION to 2
>>>
>>> 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
>>>
>>> http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a
>>> nd-kerberos-token-bloat.aspx).
>>> 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.
>>>
>>> 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.
>>>
>>> Thoughts welcome.  I'm sure I missed something along the way here but
>>> this is just what I have looked at so far.
>>>
>>> Thanks,
>>> Jeremy
>>>
>>>
>>> _______________________________________________
>>> Iudev mailing list
>>> Iudev at lists.opensfs.org
>>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>>
>> _______________________________________________
>> Iudev mailing list
>> Iudev at lists.opensfs.org
>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>
>
>
> Cheers, Andreas
>