On 04/14/2010 02:30 PM, Kevin Coffman wrote:
>> diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
>> index 8b612e7..d96d824 100644
>> --- a/net/sunrpc/auth_gss/gss_krb5_mech.c
>> +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
>> @@ -552,6 +552,7 @@ static struct gss_api_mech gss_kerberos_mech = {
>> .gm_ops = &gss_kerberos_ops,
>> .gm_pf_num = ARRAY_SIZE(gss_kerberos_pfs),
>> .gm_pfs = gss_kerberos_pfs,
>> + .gm_upcall_enctypes = "enctypes=1,2,3 ",
>> };
>
> Hi Trond,
> This list should be in preference order. It doesn't matter much with
> this one, but the preferred order for DES is usually "3,1,2".
>
> When adding 3DES, the list should be "16,3,1,2"
> When adding AES, it should be "18,17,16,3,1,2"
> When adding RC4, it should be "18,17,16,23,3,1,2"
Ok... I went back and took a second look at this... The first
thing I did was put the gm_upcall_enctypes list back in
preference order. I had no idea there was actually a theory
behind the order...
Side Note: It appears the ordering really does not matter
because the KDC is the one that decides (via the TGS-REP) which
enctype will be used and (I've been told) the KDC will always
pick the highest enctype possible.
Now the reason root was not getting its context was
basically because of the following error (which I missed)
ERROR: prepare_krb5_rfc_cfx_buffer: not implemented
Which was introduced by the third nfs-utils patch
(Add support for non-DES encryption types)
I'm currently investigating what that means...
So, Trond its up to you if you want to put that
list back in preference order, it will not matter
to the user space code...
steved.
--
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
