On Fri, May 2, 2008 at 5:39 PM, Trond Myklebust
<trond.myklebust@xxxxxxxxxx> 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 <uketinen@xxxxxxxxxx>
> > >
> > > 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);
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
