using multiple credential cache files in a server

Rick Macklem rmacklem at uoguelph.ca
Thu May 6 17:18:49 EDT 2004


rmacklem at uoguelph.ca (Rick Macklem) wrote in message news:<e31bcb6b.0404231226.5cd1a21d at posting.google.com>...
> A gssd daemon for an NFS client needs to be able to use the GSS API call
> gss_init_sec_context() on behalf of different users (uids). I can see two
> ways of doing this:
> 1 - fork off a separate child that does setuid(user_uid) to get context for
>      that user (seems inefficient)
> OR
> 2 - Get Initiator credentials for the principal and use those in the
>      gss_init_sec_context() call. This seems preferable, but requires that
>      the server switch to the credentials cache file for the appropriate uid
>      associated with that principal. (At least it seems that a credentials
>      cache file with the correct tgt is required to get Initiator Credentials.)
> 
> This leads me to my question:
> How do you get the Kerberos libraries to switch to a different credential cache
> file whenever you want to get Initiator Credentials for a different uid?
> 
I don't usually answer my own questions, but I thought someone might be
interested in how it can be done...

This works using Heimdal (but not MIT's sources, I suspect):
You can get GSS API Initiator Credentials on behalf of different users using
code something like this:
extern krb5_context gssapi_krb5_context; /* Internal, YUCK! */
gss_cred_id_t cred = NULL;

...
    /*
     * get Initiator cred for a different user.
     */
    if (cred) {
        krb5_cc_close(gssapi_krb5_context, cred->ccache);
        free(cred);
        cred = NULL;
    }
    sprintf(ccname, "/tmp/krb5cc_%d", uid);
    kret = krb5_cc_set_default_name(gssapi_krb5_context, ccname);
    if (!kret) {
         major = gss_acquire_cred(&minor, GSS_C_NO_NAME, ...);

which seems to work ok, assuming the daemon can access the different uid's
cred cache files in /tmp.

Probably not considered acceptable, since it relies on Heimdal's GSS API
internals, but it works, rick


More information about the Kerberos mailing list