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

[Kevin Coffman]

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.  Any suggestions on moving all of this
into the krb5 code, or separating out the string population w/o
creating a linking problem?

K.C.