Creating GSSAPI initiate credential using keytab entry--how should this work
Nicolas.Williams at sun.com
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 sun.com> 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