From: Usha Ketineni <[email protected]>
On NFSV4 server side, these are required as part of the security
triple(oid,qop,service) information being sent in the response of the
SECINFO operation.
Signed-off-by: Usha Ketineni <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
---
fs/nfsd/nfs4xdr.c | 6 +++---
include/linux/sunrpc/gss_api.h | 2 +-
include/linux/sunrpc/gss_krb5.h | 2 ++
net/sunrpc/auth_gss/gss_krb5_mech.c | 4 +++-
net/sunrpc/auth_gss/gss_spkm3_mech.c | 4 +++-
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index c513bbd..737dbe8 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -2512,9 +2512,9 @@ nfsd4_encode_secinfo(struct nfsd4_compoundres *resp, __be32 nfserr,
RESERVE_SPACE(4);
WRITE32(RPC_AUTH_GSS);
ADJUST_ARGS();
- RESERVE_SPACE(4 + gm->gm_oid.len);
- WRITE32(gm->gm_oid.len);
- WRITEMEM(gm->gm_oid.data, gm->gm_oid.len);
+ RESERVE_SPACE(4 + gm->gm_oid->len);
+ WRITE32(gm->gm_oid->len);
+ WRITEMEM(gm->gm_oid->data, gm->gm_oid->len);
ADJUST_ARGS();
RESERVE_SPACE(4);
WRITE32(0); /* qop */
diff --git a/include/linux/sunrpc/gss_api.h b/include/linux/sunrpc/gss_api.h
index 459c5fc..ed0b80c 100644
--- a/include/linux/sunrpc/gss_api.h
+++ b/include/linux/sunrpc/gss_api.h
@@ -76,7 +76,7 @@ struct pf_desc {
struct gss_api_mech {
struct list_head gm_list;
struct module *gm_owner;
- struct xdr_netobj gm_oid;
+ struct xdr_netobj *gm_oid;
char *gm_name;
const struct gss_api_ops *gm_ops;
/* pseudoflavors supported by this mechanism: */
diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/gss_krb5.h
index 5bb227e..65003b2 100644
--- a/include/linux/sunrpc/gss_krb5.h
+++ b/include/linux/sunrpc/gss_krb5.h
@@ -79,6 +79,8 @@ enum seal_alg {
SEAL_ALG_DES3KD = 0x0002
};
+extern struct xdr_netobj krb5_oid;
+
#define CKSUMTYPE_CRC32 0x0001
#define CKSUMTYPE_RSA_MD4 0x0002
#define CKSUMTYPE_RSA_MD4_DES 0x0003
diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
index 60c3dba..3c070d0 100644
--- a/net/sunrpc/auth_gss/gss_krb5_mech.c
+++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
@@ -232,10 +232,12 @@ static struct pf_desc gss_kerberos_pfs[] = {
},
};
+struct xdr_netobj krb5_oid = {9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"};
+
static struct gss_api_mech gss_kerberos_mech = {
.gm_name = "krb5",
.gm_owner = THIS_MODULE,
- .gm_oid = {9, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"},
+ .gm_oid = &krb5_oid,
.gm_ops = &gss_kerberos_ops,
.gm_pf_num = ARRAY_SIZE(gss_kerberos_pfs),
.gm_pfs = gss_kerberos_pfs,
diff --git a/net/sunrpc/auth_gss/gss_spkm3_mech.c b/net/sunrpc/auth_gss/gss_spkm3_mech.c
index 5deb4b6..210b23b 100644
--- a/net/sunrpc/auth_gss/gss_spkm3_mech.c
+++ b/net/sunrpc/auth_gss/gss_spkm3_mech.c
@@ -214,10 +214,12 @@ static struct pf_desc gss_spkm3_pfs[] = {
{RPC_AUTH_GSS_SPKMI, RPC_GSS_SVC_INTEGRITY, "spkm3i"},
};
+struct xdr_netobj spkm3_oid = {7, "\053\006\001\005\005\001\003"};
+
static struct gss_api_mech gss_spkm3_mech = {
.gm_name = "spkm3",
.gm_owner = THIS_MODULE,
- .gm_oid = {7, "\053\006\001\005\005\001\003"},
+ .gm_oid = &spkm3_oid,
.gm_ops = &gss_spkm3_ops,
.gm_pf_num = ARRAY_SIZE(gss_spkm3_pfs),
.gm_pfs = gss_spkm3_pfs,
On Fri, May 2, 2008 at 5:39 PM, Trond Myklebust
<[email protected]> wrote:
>
> On Fri, 2008-05-02 at 17:36 -0400, J. Bruce Fields wrote:
> > On Wed, Apr 30, 2008 at 12:46:14PM -0400, Kevin Coffman wrote:
> > > From: Usha Ketineni <[email protected]>
> > >
> > > On NFSV4 server side, these are required as part of the security
> > > triple(oid,qop,service) information being sent in the response of the
> > > SECINFO operation.
> >
> > Remind me why me need to do this?
The new downcall interface does not include the OID, so a static copy
is eventually needed. I agree this description doesn't indicate that.
This was one of the encryption patches I started with. Not an
excuse, though.
> ...and why we need to let NFSd have intimate knowledge of the gss_api
> mechanism structures. It would be _very_ nice to wrap all this up into
> some helper at the SUNRPC level with no dependencies on the RPCSEC_GSS
> code.
Agreed. Should we have a generic definition for an OID structure, or
continue to use xdr_netobj? (It is generally assumed in GSS-API that
upper-level software is aware of the OID structure.)
The gssapi spec (rfc2744) defines an oid as:
typedef struct gss_OID_desc_struct {
OM_uint32 length;
void *elements;
} gss_OID_desc, *gss_OID;
So a kernel definition might look like:
struct gss_oid {
u32 length;
void *data; /* or keep the name "elements" */
};
So the new interface would look something like one of the following?
int gss_mech_get_oid(struct gss_api_mech *gm, struct xdr_netobj **oid);
or
int gss_mech_get_oid(struct gss_api_mech *gm, struct gss_oid **oid);
On Mon, May 05, 2008 at 10:28:18AM -0400, Kevin Coffman wrote:
> On Fri, May 2, 2008 at 5:39 PM, Trond Myklebust
> <[email protected]> wrote:
> >
> > On Fri, 2008-05-02 at 17:36 -0400, J. Bruce Fields wrote:
> > > On Wed, Apr 30, 2008 at 12:46:14PM -0400, Kevin Coffman wrote:
> > > > From: Usha Ketineni <[email protected]>
> > > >
> > > > On NFSV4 server side, these are required as part of the security
> > > > triple(oid,qop,service) information being sent in the response of the
> > > > SECINFO operation.
> > >
> > > Remind me why me need to do this?
>
> The new downcall interface does not include the OID, so a static copy
> is eventually needed.
Before the patch you can get e.g. the krb5 oid from
gss_kerberos_mech->gm_oid; afterwards it's also available as krb5_oid.
If anything the former seems more useful to the downcall code, as it can
be used without requiring some particular knowledge of the krb5 code (it
only needs to know the gss-level gss_api_mech structure).
I have a feeling this patch is just a relic from a time before we had
any oid's here at all?
--b.
> I agree this description doesn't indicate that.
> This was one of the encryption patches I started with. Not an
> excuse, though.
>
> > ...and why we need to let NFSd have intimate knowledge of the gss_api
> > mechanism structures. It would be _very_ nice to wrap all this up into
> > some helper at the SUNRPC level with no dependencies on the RPCSEC_GSS
> > code.
>
> Agreed. Should we have a generic definition for an OID structure, or
> continue to use xdr_netobj? (It is generally assumed in GSS-API that
> upper-level software is aware of the OID structure.)
>
> The gssapi spec (rfc2744) defines an oid as:
>
> typedef struct gss_OID_desc_struct {
> OM_uint32 length;
> void *elements;
> } gss_OID_desc, *gss_OID;
>
> So a kernel definition might look like:
>
> struct gss_oid {
> u32 length;
> void *data; /* or keep the name "elements" */
> };
>
> So the new interface would look something like one of the following?
>
> int gss_mech_get_oid(struct gss_api_mech *gm, struct xdr_netobj **oid);
>
> or
>
> int gss_mech_get_oid(struct gss_api_mech *gm, struct gss_oid **oid);
On Wed, Apr 30, 2008 at 12:46:14PM -0400, Kevin Coffman wrote:
> From: Usha Ketineni <[email protected]>
>
> On NFSV4 server side, these are required as part of the security
> triple(oid,qop,service) information being sent in the response of the
> SECINFO operation.
Remind me why me need to do this?
--b.
>
> Signed-off-by: Usha Ketineni <[email protected]>
> Signed-off-by: J. Bruce Fields <[email protected]>
> ---
>
> fs/nfsd/nfs4xdr.c | 6 +++---
> include/linux/sunrpc/gss_api.h | 2 +-
> include/linux/sunrpc/gss_krb5.h | 2 ++
> net/sunrpc/auth_gss/gss_krb5_mech.c | 4 +++-
> net/sunrpc/auth_gss/gss_spkm3_mech.c | 4 +++-
> 5 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
> index c513bbd..737dbe8 100644
> --- a/fs/nfsd/nfs4xdr.c
> +++ b/fs/nfsd/nfs4xdr.c
> @@ -2512,9 +2512,9 @@ nfsd4_encode_secinfo(struct nfsd4_compoundres *resp, __be32 nfserr,
> RESERVE_SPACE(4);
> WRITE32(RPC_AUTH_GSS);
> ADJUST_ARGS();
> - RESERVE_SPACE(4 + gm->gm_oid.len);
> - WRITE32(gm->gm_oid.len);
> - WRITEMEM(gm->gm_oid.data, gm->gm_oid.len);
> + RESERVE_SPACE(4 + gm->gm_oid->len);
> + WRITE32(gm->gm_oid->len);
> + WRITEMEM(gm->gm_oid->data, gm->gm_oid->len);
> ADJUST_ARGS();
> RESERVE_SPACE(4);
> WRITE32(0); /* qop */
> diff --git a/include/linux/sunrpc/gss_api.h b/include/linux/sunrpc/gss_api.h
> index 459c5fc..ed0b80c 100644
> --- a/include/linux/sunrpc/gss_api.h
> +++ b/include/linux/sunrpc/gss_api.h
> @@ -76,7 +76,7 @@ struct pf_desc {
> struct gss_api_mech {
> struct list_head gm_list;
> struct module *gm_owner;
> - struct xdr_netobj gm_oid;
> + struct xdr_netobj *gm_oid;
> char *gm_name;
> const struct gss_api_ops *gm_ops;
> /* pseudoflavors supported by this mechanism: */
> diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/gss_krb5.h
> index 5bb227e..65003b2 100644
> --- a/include/linux/sunrpc/gss_krb5.h
> +++ b/include/linux/sunrpc/gss_krb5.h
> @@ -79,6 +79,8 @@ enum seal_alg {
> SEAL_ALG_DES3KD = 0x0002
> };
>
> +extern struct xdr_netobj krb5_oid;
> +
> #define CKSUMTYPE_CRC32 0x0001
> #define CKSUMTYPE_RSA_MD4 0x0002
> #define CKSUMTYPE_RSA_MD4_DES 0x0003
> diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
> index 60c3dba..3c070d0 100644
> --- a/net/sunrpc/auth_gss/gss_krb5_mech.c
> +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
> @@ -232,10 +232,12 @@ static struct pf_desc gss_kerberos_pfs[] = {
> },
> };
>
> +struct xdr_netobj krb5_oid = {9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"};
> +
> static struct gss_api_mech gss_kerberos_mech = {
> .gm_name = "krb5",
> .gm_owner = THIS_MODULE,
> - .gm_oid = {9, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"},
> + .gm_oid = &krb5_oid,
> .gm_ops = &gss_kerberos_ops,
> .gm_pf_num = ARRAY_SIZE(gss_kerberos_pfs),
> .gm_pfs = gss_kerberos_pfs,
> diff --git a/net/sunrpc/auth_gss/gss_spkm3_mech.c b/net/sunrpc/auth_gss/gss_spkm3_mech.c
> index 5deb4b6..210b23b 100644
> --- a/net/sunrpc/auth_gss/gss_spkm3_mech.c
> +++ b/net/sunrpc/auth_gss/gss_spkm3_mech.c
> @@ -214,10 +214,12 @@ static struct pf_desc gss_spkm3_pfs[] = {
> {RPC_AUTH_GSS_SPKMI, RPC_GSS_SVC_INTEGRITY, "spkm3i"},
> };
>
> +struct xdr_netobj spkm3_oid = {7, "\053\006\001\005\005\001\003"};
> +
> static struct gss_api_mech gss_spkm3_mech = {
> .gm_name = "spkm3",
> .gm_owner = THIS_MODULE,
> - .gm_oid = {7, "\053\006\001\005\005\001\003"},
> + .gm_oid = &spkm3_oid,
> .gm_ops = &gss_spkm3_ops,
> .gm_pf_num = ARRAY_SIZE(gss_spkm3_pfs),
> .gm_pfs = gss_spkm3_pfs,
>
On Fri, 2008-05-02 at 17:36 -0400, J. Bruce Fields wrote:
> On Wed, Apr 30, 2008 at 12:46:14PM -0400, Kevin Coffman wrote:
> > From: Usha Ketineni <[email protected]>
> >
> > On NFSV4 server side, these are required as part of the security
> > triple(oid,qop,service) information being sent in the response of the
> > SECINFO operation.
>
> Remind me why me need to do this?
...and why we need to let NFSd have intimate knowledge of the gss_api
mechanism structures. It would be _very_ nice to wrap all this up into
some helper at the SUNRPC level with no dependencies on the RPCSEC_GSS
code.
> --b.
>
> >
> > Signed-off-by: Usha Ketineni <[email protected]>
> > Signed-off-by: J. Bruce Fields <[email protected]>
> > ---
> >
> > fs/nfsd/nfs4xdr.c | 6 +++---
> > include/linux/sunrpc/gss_api.h | 2 +-
> > include/linux/sunrpc/gss_krb5.h | 2 ++
> > net/sunrpc/auth_gss/gss_krb5_mech.c | 4 +++-
> > net/sunrpc/auth_gss/gss_spkm3_mech.c | 4 +++-
> > 5 files changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
> > index c513bbd..737dbe8 100644
> > --- a/fs/nfsd/nfs4xdr.c
> > +++ b/fs/nfsd/nfs4xdr.c
> > @@ -2512,9 +2512,9 @@ nfsd4_encode_secinfo(struct nfsd4_compoundres *resp, __be32 nfserr,
> > RESERVE_SPACE(4);
> > WRITE32(RPC_AUTH_GSS);
> > ADJUST_ARGS();
> > - RESERVE_SPACE(4 + gm->gm_oid.len);
> > - WRITE32(gm->gm_oid.len);
> > - WRITEMEM(gm->gm_oid.data, gm->gm_oid.len);
> > + RESERVE_SPACE(4 + gm->gm_oid->len);
> > + WRITE32(gm->gm_oid->len);
> > + WRITEMEM(gm->gm_oid->data, gm->gm_oid->len);
> > ADJUST_ARGS();
> > RESERVE_SPACE(4);
> > WRITE32(0); /* qop */
> > diff --git a/include/linux/sunrpc/gss_api.h b/include/linux/sunrpc/gss_api.h
> > index 459c5fc..ed0b80c 100644
> > --- a/include/linux/sunrpc/gss_api.h
> > +++ b/include/linux/sunrpc/gss_api.h
> > @@ -76,7 +76,7 @@ struct pf_desc {
> > struct gss_api_mech {
> > struct list_head gm_list;
> > struct module *gm_owner;
> > - struct xdr_netobj gm_oid;
> > + struct xdr_netobj *gm_oid;
> > char *gm_name;
> > const struct gss_api_ops *gm_ops;
> > /* pseudoflavors supported by this mechanism: */
> > diff --git a/include/linux/sunrpc/gss_krb5.h b/include/linux/sunrpc/gss_krb5.h
> > index 5bb227e..65003b2 100644
> > --- a/include/linux/sunrpc/gss_krb5.h
> > +++ b/include/linux/sunrpc/gss_krb5.h
> > @@ -79,6 +79,8 @@ enum seal_alg {
> > SEAL_ALG_DES3KD = 0x0002
> > };
> >
> > +extern struct xdr_netobj krb5_oid;
> > +
> > #define CKSUMTYPE_CRC32 0x0001
> > #define CKSUMTYPE_RSA_MD4 0x0002
> > #define CKSUMTYPE_RSA_MD4_DES 0x0003
> > diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
> > index 60c3dba..3c070d0 100644
> > --- a/net/sunrpc/auth_gss/gss_krb5_mech.c
> > +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
> > @@ -232,10 +232,12 @@ static struct pf_desc gss_kerberos_pfs[] = {
> > },
> > };
> >
> > +struct xdr_netobj krb5_oid = {9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"};
> > +
> > static struct gss_api_mech gss_kerberos_mech = {
> > .gm_name = "krb5",
> > .gm_owner = THIS_MODULE,
> > - .gm_oid = {9, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"},
> > + .gm_oid = &krb5_oid,
> > .gm_ops = &gss_kerberos_ops,
> > .gm_pf_num = ARRAY_SIZE(gss_kerberos_pfs),
> > .gm_pfs = gss_kerberos_pfs,
> > diff --git a/net/sunrpc/auth_gss/gss_spkm3_mech.c b/net/sunrpc/auth_gss/gss_spkm3_mech.c
> > index 5deb4b6..210b23b 100644
> > --- a/net/sunrpc/auth_gss/gss_spkm3_mech.c
> > +++ b/net/sunrpc/auth_gss/gss_spkm3_mech.c
> > @@ -214,10 +214,12 @@ static struct pf_desc gss_spkm3_pfs[] = {
> > {RPC_AUTH_GSS_SPKMI, RPC_GSS_SVC_INTEGRITY, "spkm3i"},
> > };
> >
> > +struct xdr_netobj spkm3_oid = {7, "\053\006\001\005\005\001\003"};
> > +
> > static struct gss_api_mech gss_spkm3_mech = {
> > .gm_name = "spkm3",
> > .gm_owner = THIS_MODULE,
> > - .gm_oid = {7, "\053\006\001\005\005\001\003"},
> > + .gm_oid = &spkm3_oid,
> > .gm_ops = &gss_spkm3_ops,
> > .gm_pf_num = ARRAY_SIZE(gss_spkm3_pfs),
> > .gm_pfs = gss_spkm3_pfs,
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html