support for Kerberos credential cache locations other than FILE:?
James Ralston
qralston+ml.openssh-unix-dev at andrew.cmu.edu
Thu Dec 4 10:22:23 EST 2014
The MIT Kerberos library has supported credential cache locations
other than "FILE:" for a while now:
http://web.mit.edu/kerberos/krb5-devel/doc/basic/ccache_def.html
In fact, RHEL7 sets the default credential cache to use the kernel
keyring, via the new(ish) "default_ccache_name" option in
/etc/krb5.conf:
[libdefaults]
default_ccache_name = KEYRING:persistent:%{uid}
However, this will break forwarding Kerberos credentials via
GSSAPIDelegateCredentials. But I'm not sure why, since openssh
hardcodes the location of the Kerberos credential cache in
auth-krb5.c:
ret = snprintf(ccname, sizeof(ccname),
"FILE:/tmp/krb5cc_%d_XXXXXXXXXX", geteuid());
tmpfd = mkstemp(ccname + strlen("FILE:"));
...
return (krb5_cc_resolve(ctx, ccname, ccache));
Based on this, I would expect openssh to blast over the library
default, but when I test, I see $KRB5CCNAME set to (e.g.)
KEYRING:persistent:12345, but without credentials in it. (And tracing
the sshd process shows that it never attempted to create any
file-based credential cache.)
So, two questions:
First, does anyone know what happens to the credential cache openssh
creates when the library default location is a keyring? Openssh isn't
logging any errors, so I don't think the various krb5 library
functions are failing. Has anyone else already played around with
this?
Second, is there a reason why openssh hardcodes the ccname location,
instead of using krb5_cc_default_name() to obtain the library default?
The only reason I can see for doing this is because if the library
default starts with FILE: or DIR:, then you need to append
"XXXXXXXXXX" (if necessary) and then use mkstemp() to get a
non-predictable location. So that would be a little more effort than
what openssh currently does.
However, this would enable openssh to support Kerberos credential
types other than "FILE:", so I'd argue it's worth it.
Am I missing something? Is there a specific reason why openssh
doesn't already do this?
More information about the openssh-unix-dev
mailing list