[PATCH 0/2] Give svcgssd access to kernel's supported enctypes

[PATCH 0/2] Give svcgssd access to kernel's supported enctypes

[Kevin Coffman]

Make the kernel's supported enctypes available to user-land
(svcgssd) via a new proc file.  The client side already gets
this information in the upcall to gssd, we need to make it
available to svcgssd.

[PATCH 1/2] gss:krb5 only include enctype numbers in gm_upcall_enctypes

[Kevin Coffman]

Make the value in gm_upcall_enctypes just the enctype values.
This allows the values to be used more easily elsewhere.

Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
---
 net/sunrpc/auth_gss/auth_gss.c      |    2 +-
 net/sunrpc/auth_gss/gss_krb5_mech.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 45dbf15..f3914d0 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -417,7 +417,7 @@ static void gss_encode_v1_msg(struct gss_upcall_msg *gss_msg,
 		gss_msg->msg.len += len;
 	}
 	if (mech->gm_upcall_enctypes) {
-		len = sprintf(p, mech->gm_upcall_enctypes);
+		len = sprintf(p, "enctypes=%s ", mech->gm_upcall_enctypes);
 		p += len;
 		gss_msg->msg.len += len;
 	}
diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
index f375dec..9022f0a 100644
--- a/net/sunrpc/auth_gss/gss_krb5_mech.c
+++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
@@ -750,7 +750,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=18,17,16,23,3,1,2 ",
+	.gm_upcall_enctypes = "18,17,16,23,3,1,2",
 };
 
 static int __init init_kerberos_module(void)
-- 
1.7.3.4

[PATCH 2/2] nfsd: add proc file listing kernel's gss_krb5 enctypes

[Kevin Coffman]

Add a new proc file which lists the encryption types supported
by the kernel's gss_krb5 code.

Newer MIT Kerberos libraries support the assertion of acceptor
subkeys.  This enctype information allows user-land (svcgssd)
to request that the Kerberos libraries limit the encryption
types that it uses when generating the subkeys.

Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
---
 fs/nfsd/nfsctl.c |   31 ++++++++++++++++++++++++++++++-
 1 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index 33b3e2b..35dcfa8 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -12,13 +12,14 @@
 #include <linux/nfsd/syscall.h>
 #include <linux/lockd/lockd.h>
 #include <linux/sunrpc/clnt.h>
+#include <linux/sunrpc/gss_api.h>
 
 #include "idmap.h"
 #include "nfsd.h"
 #include "cache.h"
 
 /*
- *	We have a single directory with 9 nodes in it.
+ *	We have a single directory with several nodes in it.
  */
 enum {
 	NFSD_Root = 1,
@@ -42,6 +43,7 @@ enum {
 	NFSD_Versions,
 	NFSD_Ports,
 	NFSD_MaxBlkSize,
+	NFSD_SupportedEnctypes,
 	/*
 	 * The below MUST come last.  Otherwise we leave a hole in nfsd_files[]
 	 * with !CONFIG_NFSD_V4 and simple_fill_super() goes oops
@@ -187,6 +189,32 @@ static struct file_operations export_features_operations = {
 	.release	= single_release,
 };
 
+static int supported_enctypes_show(struct seq_file *m, void *v)
+{
+	struct gss_api_mech *k5mech;
+
+	k5mech = gss_mech_get_by_name("krb5");
+	if (k5mech == NULL)
+		goto out;
+	if (k5mech->gm_upcall_enctypes != NULL)
+		seq_printf(m, k5mech->gm_upcall_enctypes);
+	gss_mech_put(k5mech);
+out:
+	return 0;
+}
+
+static int supported_enctypes_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, supported_enctypes_show, NULL);
+}
+
+static struct file_operations supported_enctypes_ops = {
+	.open		= supported_enctypes_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+
 extern int nfsd_pool_stats_open(struct inode *inode, struct file *file);
 extern int nfsd_pool_stats_release(struct inode *inode, struct file *file);
 
@@ -1397,6 +1425,7 @@ static int nfsd_fill_super(struct super_block * sb, void * data, int silent)
 		[NFSD_Versions] = {"versions", &transaction_ops, S_IWUSR|S_IRUSR},
 		[NFSD_Ports] = {"portlist", &transaction_ops, S_IWUSR|S_IRUGO},
 		[NFSD_MaxBlkSize] = {"max_block_size", &transaction_ops, S_IWUSR|S_IRUGO},
+		[NFSD_SupportedEnctypes] = {"supported_krb5_enctypes", &supported_enctypes_ops, S_IRUGO},
 #ifdef CONFIG_NFSD_V4
 		[NFSD_Leasetime] = {"nfsv4leasetime", &transaction_ops, S_IWUSR|S_IRUSR},
 		[NFSD_Gracetime] = {"nfsv4gracetime", &transaction_ops, S_IWUSR|S_IRUSR},
-- 
1.7.3.4

Re: [PATCH 0/2] Give svcgssd access to kernel's supported enctypes

[J. Bruce Fields]

On Wed, Mar 02, 2011 at 07:51:40PM -0500, Kevin Coffman wrote:
> Make the kernel's supported enctypes available to user-land
> (svcgssd) via a new proc file.  The client side already gets
> this information in the upcall to gssd, we need to make it
> available to svcgssd.

They look good to me; I'll queue them up for 2.6.39 if nobody else sees
a problem.

Do you have the nfs-utils bits ready as well?

--b.

Re: [PATCH 0/2] Give svcgssd access to kernel's supported enctypes

[Kevin Coffman]

On Thu, Mar 3, 2011 at 1:26 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Wed, Mar 02, 2011 at 07:51:40PM -0500, Kevin Coffman wrote:
>> Make the kernel's supported enctypes available to user-land
>> (svcgssd) via a new proc file.  The client side already gets
>> this information in the upcall to gssd, we need to make it
>> available to svcgssd.
>
> They look good to me; I'll queue them up for 2.6.39 if nobody else sees
> a problem.
>
> Do you have the nfs-utils bits ready as well?
>
> --b.

I do, but I wanted to try and add something to detect whether the
Kerberos code has been updated to honor the request to limit the
encryption types (in the accept_sec_context path), and give a helpful
warning message.  However, that may turn out to be more work than it
is worth.  I will be sending patches soon.

K.C.