[krbdev.mit.edu #2060] GSSAPI does not pick up the CCAPI system default ccache

[Alexandra Ellwood via RT]

There are two different "default ccache" names running around on OSes
using CCAPI v3 and higher (currently just the Mac).  There is the system
default ccache and the context default ccache. 

The system default ccache is stored on the CCacheServer and is the same
for all applications.   People familiar with normal UNIX Kerberos can
think of the system default ccache as being similar to the environment
variable KRB5CCNAME, except that it is login session global rather than
being inherited from process to process.  Changing the system default
ccache from one application changes it for all applications in that
user's login session.

The name of the system default ccache can be obtained programmatically
by calling the CCAPI v3 function cc_context_get_default_ccache_name(). 
Users can see the name of the system default ccache by looking at the
underlined principal in Kerberos.app or running klist.  They can change
the system default ccache by selecting a new principal and clicking the
"Make User Active" button in Kerberos.app or by running the command line
program kswitch.

The context default ccache is per krb5_context, KClient session.  When
an application creates a new krb5_context or KClient session, the
context default ccache will be set to the current value of the system
default ccache.  Once set, the context default ccache is never re-synced
with the system default ccache unless the application manually sets it
to that value.  This behavior is critical for KClient because v4 has no
concept of an auth context. 

The context default ccache is never visible to the user unless the
application chooses to display it (such as a status bar that says
something like "authenticated as lxs at ATHENA.MIT.EDU").  It can be
obtained programmatically with  krb5_cc_default_name (context) or
KClientGetCCacheReference (session, &ccache).

The problem is that the krb5_context used by GSSAPI is a single global
variable.  As a result, the context default ccache and principal get
cached when the library initializes.  This means that the library always
uses whatever the default ccache was as the time the application
launched.  Obviously if you have a single long-running application which
 has multiple connection windows, you don't want to be stuck with a
single set of tickets.  

As you might have noticed, Fetch and some other GSSAPI applications on
the Mac don't actually have this behavior.  The reason for this is that
they can work around the problem by using the private API
gss_krb5_ccache_name() to manually reset the ccache name in GSSAPI's
krb5_context.  The problem is, gss_krb5_ccache_name() is a private API
-- not even part of the GSSAPI C Bindings -- and really should be avoided.

Although the application can set the context default ccache
programmatically, it shouldn't have to (or be encouraged to).  There
should be a general, consistent way for the user to set the default
credentials used by new connections which works for all applications,
similar to the way KRB5CCNAME works for short running command line
applications.  If we don't provide a way for the library to
automatically do this by default, then every application will end up
needing to write the same code using the same private API.

Instead GSSAPI should by default pick up the system default ccache
whenever GSSAPI tries to acquire a new set of initial credentials
(gss_acquire_cred/gss_init_sec_context). In order to allow applications
to have their own custom behavior (such as sticking with a single ccache
all the time) we should also continue to support the use of
gss_krb5_ccache_name().