[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sam Hartman] Re: Proposal to export gssapi context




Forgot to copy this to here.




>>>>> "kwc" == Kevin Coffman <kwc@citi.umich.edu> writes:

    kwc> Brought to krbdev...

    kwc> The kernel implementation of rpcsec_gss used for NFSv4 requires context
    kwc> information be negotiated in user-land and then passed down for use in the
    kwc> kernel.  gss_export_context() exports the context as an opaque object which
    kwc> cannot be used for this purpose.  We are proposing three new APIs.  One is
    kwc> to restrict the encryption types negotiated in user-land to the set that the
    kwc> kernel can use.  The other two are to export context information into a
    kwc> usable structure, and then free that structure.

    kwc> Comments, suggestions, welcome.

#define GSS_C_LUCID_CONTEXT_CURRENT_VERSION	GSS_C_LUCID_CONTEXT_VERSION_1

I don't think having a macro for the current version in a public
header is a good idea.  People might use it and failing to think of a
way of using it that would be correct.


 typedef struct gss_krb5_lucid_context {

The version number should be in the structure name.

It seems like you actually only need two keys: the context key and the
server subkey.  You can determine the sequence key from the context
key.  As Ken pointed out you don't need both enctypes and keys; the
key contains the enctype.

Presumably the return from krb5_gss_export_lucid_context should be a
void * and cast by the caller after looking at the version numbers.


--Sam
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev