Memory Callback support in GSSAPI

[Manoj Mohan]

Hi Tom,

We have our own threading model and scheduler.. so that we can have better
control. In this design, there can be multiple processes batched by the
type of work they can do (Like encryption work will go on type of
processes, IO on another etc). In order to ensure that work can be
scheduled on any one of them, the structures should come out of shared
memory. For instance,

Server side code snippet/logic
========================
    gss_cred_id_t          verifier_cred_handle;
    gss_ctx_id_t           context_handle;
    gss_name_t             src_name = NULLPTR;
    gss_OID                actual_mech_type=0;
    gss_channel_bindings_t input_chan_bindings = GSS_C_NO_CHANNEL_BINDINGS;
    gss_buffer_desc        gss_input_token, gss_output_token;
    uint4                  ret_flags=0;
    OM_uint32              time_ret=0;
    gss_cred_id_t          delegated_cred_handle=0;
........................
 /* called gss_import_name to convert the server principal */
maj_stat = gss_import_name(&min_stat, &name_buffer,
#ifndef NT
                               GSS_C_NT_USER_NAME,
#else
                               GSS_C_NULL_OID,
#endif /* !NT */
                               &server_name_internal);
.............................
/* Called gss_acquire_cred to get the credential */
/* Internally we are calling gss_acquire_cred with GSS_C_ACCEPT */
   if (get_cred_from_keytab(server_name_internal, &verifier_cred_handle,
time_req, &time_ret, status)
................................
/* This verifier_cred_handle is then passed to gss_accept_sec_context */
    maj_stat = gss_accept_sec_context(&min_stat, &context_handle,
verifier_cred_handle, &gss_input_token,
                                      input_chan_bindings, &src_name,
&actual_mech_type, &gss_output_token,
                                      &ret_flags, &time_ret,
&delegated_cred_handle);
/* Once successful we go ahead and save this in our structure some where */
/* However this is NOT coming from shared memory, so when the thread
migrates to a different process */
/* it bombs */


So far I have always worked with libraries which provide certain APIs to
register our shared memory callbacks for malloc/realloc and free. However,
in order to implement SSO (we support only Kerberos V), we decided to use
os provided library (libgss) and somehow I don't see any such API... I am
trying to read more on this but nothing too relevant is coming up on web..
any pointers would be great.

I have registered my id in the mailing list... would love to contribute..

Regards,
Manoj


                                                                                                             
  From:       Tom Yu <tlyu at MIT.EDU>                                                                          
                                                                                                             
  To:         Manoj Mohan/Lenexa/IBM at IBMUS                                                                   
                                                                                                             
  Cc:         "kerberos at mit.edu" <kerberos at MIT.EDU>                                                          
                                                                                                             
  Date:       11/11/2009 11:31 AM                                                                            
                                                                                                             
  Subject:    Re: Memory Callback support in GSSAPI                                                          
                                                                                                             





Manoj Mohan <manojm at us.ibm.com> writes:

> In order to ensure that server side code for Single-Sign-On runs can run
on
> multiple processes, I wanted to find out if there any available APIs to
> register memory callback functions for malloc/realloc/free. Right now I
can
> see that when I call functions like
gss_acquire_cred/gss_sec_accept_context
> the credential handle will come out of heap/process memory and when the
> thread will migrate to another process it will be invalid.

Would you please explain what sort of cross-process thread migration
is involved?  The gss_export_sec_context and gss_import_sec_context
functions should accomplish most anticipated cross-process migration
of GSS-API state; is there a particular reason you need to migrate a
credential handle?

> If memory callback functions are not there.. what is the best way to
handle
> this?

Memory callback functions aren't present in the current API.  Are you
considering placing such structures in shared memory or something
similar?

The GSS-API is an IETF standards-track specification; it so happens
that the IETF KITTEN Working Group is contemplating some API
revisions, and we could use some input from application developers and
others who have a desire to improve the API.  The idea of memory
management callback functions is one direction that some KITTEN
Working Group participants have mentioned as a possible improvement.

The Working Group charter is at

    http://www.ietf.org/dyn/wg/charter/kitten-charter.html

and the mailing list archive is at

    http://www.ietf.org/mail-archive/web/kitten/current/maillist.html

Please consider participating in the Working Group by joining its
mailing list; while of course I can relay suggestions that people post
to the Kerberos mailing list/newsgroup, direct participation in the
Working Group is also valuable.

--
Tom Yu
Development Team Leader
MIT Kerberos Consortium
(and IETF KITTEN WG co-chair)