Heads-up: Kerberos default user credential cache location is changing
sgallagh at redhat.com
Thu Jun 21 18:00:44 UTC 2012
As part of two related Fedora 18 Features, the default location
that Kerberos credential caches will be stored (when logging in through
SSSD or pam_krb5) will be changing from its existing location of
FILE:/tmp/krb5cc_UID_XXXXXX to a new default of DIR:/run/user/UID/ccdir
This gains multiple advantages:
1) Credential caches are now stored in a tmpfs location. This is a
security feature, as a stolen laptop may not be booted in single-user
mode to extract a valid TGT.
2) Credential caches have switched to the DIR: cache type, which allows
acquiring tickets for multiple Kerberos realms simultaneously. This
means that you can have SSO credentials for the realm you logged into,
as well as getting additional credentials for other realms (example
case: login to your corporate account, also get kerberos credentials for
a partner account).
3) The credential cache is now stored in a well-known and
better-protected location than /tmp. Applications such as GSSD that
require access to a user's Kerberos credential cache can now know to
look specifically at DIR:/run/user/UID/ccdir, rather than trolling /tmp
for a credential cache they have privilege to read.
Some users may be surprised at the loss of reboot-persistent credential
caches, despite the obvious security benefits. In that case, SSSD and
pam_krb5 can be configured to store the credentials in a different,
persistent location. It's important to note that, due to the proposal to
change /tmp to tmpfs and/or encapsulate it in a pam_namespace, keeping
the credentials in /tmp would still have changed this default behavior.
This email is intended to inform any Kerberos-using applications that
they should start making themselves capable of using the new default
location for credential caches. Those who wish to test this with SSSD
Kerberos logins can do so with sssd-1.9.0-7.fc18.beta2 which should be
available in your local rawhide mirror by now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the devel