Creating GSSAPI initiate credential using keytab entry--how should this work

Nicolas Williams Nicolas.Williams at
Wed Mar 10 14:51:12 EST 2010

On Wed, Mar 10, 2010 at 11:36:09AM -0800, Russ Allbery wrote:
> Nicolas Williams <Nicolas.Williams at> writes:
> > The main issue is: how to find the correct keytab.  Using an environment
> > variable will do, but I'd rather have well-known locations for user
> > keytabs, such as:
> >     /var/run/krb5/keytabs/<user>/keytab
> >     /var/krb5/keytabs/<user>/keytab
> > The /var/run paths would be nice for system-managed temporary keytabs
> > (think of a PAM module stashing away your keys for subsequent use; I'm
> > not promoting this, but I'd like it to be possible).  The /var/krb5
> > paths would be nice for persistent user keytabs.
> I suspect the second path will vary widely between systems.  For instance,
> Linux systems following the File Hierarchy Standard would not be permitted
> to use /var/krb5,

Indeed, but this is a matter of build-time configuration.  On Solaris
we'd use /var/run/krb5 and /var/krb5.  Various Linux, *BSD and
OpenSolaris distros could do whatever else they please.

>                   and I think the most reasonable interpretation of the
> FHS would be that persistent keytabs are configuration files and therefore
> must be in /etc.

But we're talking about _user_ content, not system content.

Such contents is best placed in $HOME, but then you get into a catch-22
if you need [fresh] credentials to access $HOME, and, of course, you'd
want to encrypt such credentials in case they are not confidentiality-
protected on the wire.  It's easier to use local storage, and /var seems
right for that.  Personally, I'd disallow persistent user keytabs and go
with /var/run only as a matter of _policy_, but I think the system
should support persistent user keytabs as well.


More information about the krbdev mailing list