Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred()

[Nico Williams <[e-mail]>]

On Thu, Mar 19, 2015 at 11:20:09AM -0400, Simo Sorce wrote:
> I guess it may be surprising in some cases, and expected in others,
> unfortunately.
> If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you
> expect a default ccache to be created with whatever is in the keytab for
> example. But you'd be surprised otherwise.

Since it's both, sometimes surprising and sometimes expected, you get to
pick what to end up with.  Perhaps one behavior will cause more customer
calls than the other.

But I think there are compromises that get you (a) without breaking
anyone.  Again:

 - have a shadow default ccache for the case of acquiring a credential
   from a keytab when there is no default ccache

 - use the DIR ccache (does it have the option of not setting a default
   ccache in the collection?)

 - don't cache tickets when the default ccache does not exist

 - if there are keys for only one principal in the keytab, then set
   the default principal, else don't (and use one of the above fixes)

And you could always add yet another environment variable, and/or
krb5.conf parameter.

To me it seems clear that GSS applications that do simple things like
GSS_Init/Accept_sec_context() with the GSS_C_NO_CREDENTIAL, or which
call GSS_Acquire/Add_cred(), do not cause other processes in the system
to "break".  Actually, this should be true for all GSS apps that do not
call GSS_Store_cred() (whose entire purpose is to have side-effects).

Even if you change nothing, I'm inclined to say that (a) is preferred
and note that (b) is what one sometimes gets, therefore one must read
the implementation's docs.  I'd like to see this fixed (see above).

Nico
--