[OpenAFS] Re: Any budding documentation writers

[Russ Allbery]

Jeffrey Altman <jaltman@secure-endpoints.com> writes:

> As with any Kerberos based GSSAPI mechanism there needs to be a
> credential cache.  Even klog.krb5 uses a credential cache.  It just
> destroys the contents of the cache it creates after it is finished.  The
> difference is that klog.krb5 is capable of directly requesting the
> afs[/<cell>]@<REALM> service ticket and does not need to first obtain a
> TGT.  When the GSSAPI krb5 mechanism is used, a TGT is always required.
> The GSSAPI, being mechanism agnostic, does not provide a method to
> obtain initial credentials.

The root of the problems around usability of GSSAPI with Kerberos are
primarily that the integration between Kerberos and GSSAPI at a local
configuration level (as opposed to the network protocol level) is frankly
horrible.  The GSSAPI Kerberos mechanism is a Kerberos client that wants
to use a conventional Kerberos ticket cache, and a Kerberized application
that's using GSSAPI is also a Kerberos client, but there's absolutely no
mechanism in the GSSAPI API for them to communicate important details
between then since all communication is forced through a mech-independent
layer.

It's not surprising that this is true, and it's fairly obvious why it's
set up this way.  However, it causes a wide variety of practical problems
and makes working with GSSAPI occasionally very painful.  You simply
cannot do obvious and reasonable things that you would be able to do in a
pure Kerberos application, such as avoid using a Kerberos ticket cache,
reasonably share Kerberos credentials between the application and the
GSSAPI library, reasonably override local Kerberos configuration for the
GSSAPI Kerberos mechanism implementation, and so forth.  You're forced
into horrible hacks that aren't thread-safe and have unintended
consequences.

This isn't something that can be properly fixed in any one GSSAPI client
application.  It really needs API help from the GSSAPI layer to provide
some sort of mechanism-specific escape route so that you can do some
Kerberos-specific configuration of the GSSAPI library behavior.  Some
Kerberos GSSAPI implementations have some non-standardized APIs for doing
some of this, but I've never found everything that I really wanted.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>