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.
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 <[email protected]>
---
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
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.
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 <[email protected]>
---
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
On Thu, Mar 3, 2011 at 1:26 AM, J. Bruce Fields <[email protected]> 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.