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

[Chuck Lever]

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.

>>> +
>>> +static int
>>> +rpc_krb5_info_open(struct inode *inode, struct file *file)
>>> +{
>>> +     return single_open(file, rpc_show_krb5_info, NULL);
>>> +}
>>> +
>>> +static struct file_operations krb5_info_operations = {
>>> +     .owner          = THIS_MODULE,
>>> +     .open           = rpc_krb5_info_open,
>>> +     .read           = seq_read,
>>> +     .llseek         = seq_lseek,
>>> +     .release        = single_release,
>>> +};
>>> +
>>>
>>>  /*
>>>   * We have a single directory with 1 node in it.
>>> @@ -396,6 +421,7 @@ enum {
>>>       RPCAUTH_nfs,
>>>       RPCAUTH_portmap,
>>>       RPCAUTH_statd,
>>> +     RPCAUTH_krb5_info,
>>>       RPCAUTH_RootEOF
>>>  };
>>>
>>> @@ -429,6 +455,11 @@ static struct rpc_filelist files[] = {
>>>               .name = "statd",
>>>               .mode = S_IFDIR | S_IRUGO | S_IXUGO,
>>>       },
>>> +     [RPCAUTH_krb5_info] = {
>>> +             .name = "krb5_info",
>>> +             .i_fop = &krb5_info_operations,
>>> +             .mode = S_IFREG | S_IRUSR,
>>> +     },
>>>  };
>>>
>>>  enum {
>>
>>  --
>>  Chuck Lever
>>  chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
>>

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