[PATCH 11/28] Add new pipefs file indicating which Kerberos enctypes the kernel supports

[Chuck Lever]

On Mar 31, 2008, at 2:19 PM, Kevin Coffman wrote:
> On Mon, Mar 31, 2008 at 1:04 PM, Chuck Lever  
> <chuck.lever at oracle.com> wrote:
>> On Mar 31, 2008, at 12:51 PM, Kevin Coffman wrote:
>>> On Mon, Mar 31, 2008 at 11:47 AM, Chuck Lever
>>> <chuck.lever at oracle.com> wrote:
>>>> On Mar 31, 2008, at 10:31 AM, Kevin Coffman wrote:
>>>>> New file, krb5_info, indicates which Kerberos encryption types are
>>>>> supported by the kernel rpcsecgss code.  This is used by gssd to
>>>>> determine which encryption types it should attempt to negotiate
>>>>> when creating a context with a server.
>>>>>
>>>>> The server principal's database and keytab encryption types are
>>>>> what limits what it should negotiate.  Therefore, its keytab
>>>>> should be created with only the enctypes listed by this file.
>>>>>
>>>>> From: J. Bruce Fields <bfields at citi.umich.edu>
>>>>> Signed-off-by: Kevin Coffman <kwc at citi.umich.edu>
>>>>> ---
>>>>>
>>>>>  net/sunrpc/rpc_pipe.c |   31 +++++++++++++++++++++++++++++++
>>>>>  1 files changed, 31 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
>>>>> index 1b395a4..a006f9f 100644
>>>>> --- a/net/sunrpc/rpc_pipe.c
>>>>> +++ b/net/sunrpc/rpc_pipe.c
>>>>> @@ -385,6 +385,31 @@ static const struct file_operations
>>>>> rpc_info_operations = {
>>>>>       .release        = rpc_info_release,
>>>>>  };
>>>>>
>>>>> +/*
>>>>> + * This really belongs in the gss_krb5 code,
>>>>> + * but the info file logically belongs here
>>>>> + */
>>>>> +static int
>>>>> +rpc_show_krb5_info(struct seq_file *m, void *v)
>>>>> +{
>>>>> +     seq_printf(m, "enctypes: 3,1,2\n");
>>>>> +     return 0;
>>>>> +}
>>>>
>>>>  Okay, like, what the hell do these numbers mean?  :-)  These  
>>>> should
>>>>  be generated programmatically rather than hard-coded so we can
>>>>  understand exactly what these numbers are and how they are  
>>>> derived.
>>>
>>> First, these are the ENCTYPE definition values from the Kerberos
>>> specs.
>>>
>>> Somewhere we need a list of the supported enctypes.  (Since for DES
>>> and DES3 types, serveral krb5 enctypes are mapped to a single  
>>> enctype
>>> for GSS use, we can't simply use the list of enctypes defined in the
>>> framework.)
>>>
>>> "3,1,2" represent ENCTYPE_DES_CBC_MD5, ENCTYPE_DES_CBC_CRC, and
>>> ENCTYPE_DES_CBC_MD4.  Would you prefer something like the following?
>>>
>>> snprintf(buf, sizeof(buf), "enctypes: %d,%d,%d\n",
>>>     ENCTYPE_DES_CBC_MD5,
>>>     ENCTYPE_DES_CBC_CRC,
>>>     ENCTYPE_DES_CBC_MD4);
>>> /* check for buffer truncation */
>>> seq_print(m, buf);
>>
>>  That's better, but I was thinking of something even more automated.
>>  You have the enctype array; could you iterate over that to generate
>>  this list, and then eliminate duplicates?  That way, this function
>>  would not have to be updated when you add new types.
>>
>>  Basically you want to make the process of adding a new enctype as
>>  automatic as possible so that it is impossible for developers to get
>>  this wrong.
>
> The population of this string belongs elsewhere (in the
> rpcsec_gss_krb5 module).  I actually tried something similar before
> and ran into linking problems.

I suspected that linking problems might have been the root issue.

> Any suggestions on moving all of this
> into the krb5 code, or separating out the string population w/o
> creating a linking problem?

Usually the approach is to create an API that allows each object  
(enctype, flavor, capability) to register with the generic  
infrastructure.  Each object can provide metadata or methods that the  
generic infrastructure can use to present a coherent picture of what  
capabilities are present to other parts of the kernel, and to user  
space.

RPC transport capabilities and device mapper targets are two examples  
of this approach.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com