I am using MIT Kerberos 1.2.6.

I am writing an application which does multiple gss_init_sec_context on
behalf of various kerberos principals / unix users (basically the
application does a setuid) and also as different users (like
uid=101,102). The application would do a setuid to appropriate user id
(and let us assume the credentials has been already obtained by that
user).
Now the problem I hit is that I am not able to do a gss_init_sec_context
for a different user once the first gss_init_sec_context has been called
successfully.

The problem I believe is that the default credential cache has already
been setup during the first call and the same is being returned for
subsequent init_sec_context. This is because the kg_context
(krb5_context) defined as static in the gssapi_krb5.c and has already
been initialized. Is there any consequence of making this a global and
if we do a gss_release_cred before the next gss_init_sec_context to
clear this default context out.
If you just want gss_init_sec_context to pick up new credentials in the same ccache (such as when tickets expire and the user gets new ones), you can call gss_release_cred() with a gss_cred_id_t_handle of GSS_C_NO_CREDENTIAL. This will destroy the internally cached credentials. The new call to gss_init_sec_context() will load the new ones.

To switch between multiple sets of krb5 credentials in different ccaches, you should instead use gss_krb5_ccache_name() to change the name of the ccache in the kg_context. Although gss_krb5_ccache_name() can optionally return the old ccache name, there is a bug in the 1.2.x releases where it actually returns the new name, so don't depend on being able to get the old ccache name.


Hope this helps,

--lxs
--
-----------------------------------------------------------------------------
Alexandra Ellwood <[EMAIL PROTECTED]>
MIT Information Systems http://mit.edu/lxs/www/
-----------------------------------------------------------------------------
--
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to