KRB5 Credential Cache Move
This Feature changes the default location of Kerberos credential cache from living in /tmp/krb5cc_UID_XXXXXX to being /run/user/$USERNAME/krb5cc
- Name: Stephen Gallagher
- Email: email@example.com
- Targeted release: Fedora 18
- Last updated: 2012-02-23
- Percentage of completion: 10%
Packages that create Kerberos credential caches on behalf of a user (real or system) will need to change where this cache is stored.
Benefit to Fedora
The reason is to make credential saving a bit more predictable while at the same time avoiding races. Along the road we also gain a little bit more security by the fact that /run is a tmpfs and therefore cached credentials are automatically removed if the machine is shut off.
For daemons that use a keytab to kinit because they act as clients (as opposed to just server that accept kerberos connections), it may be needed to add a configuration snippet in their configuration file under /etc/tmpfiles.d so that /run/user/<username> is created with the correct permissions (700) and user ownership.
For example, httpd would add the following line to the /etc/tmpfiles.d/httpd.conf:
d /var/run/user/apache 700 apache apache
If you know your daemon requires a credential cache file and does not specify one on its own but instead relies on the default location, then you should open a ticket in bugzilla and add the necessary configuration to tmpfiles.d
How To Test
1. Verify that when logging in through SSSD or pam_krb5 that the credential cache listed by 'klist' is FILE:/run/user/$USERNAME/krb5cc 2. Verify that applications such as apache (used with mod-auth_kerb) put their credential caches in /run/user/$SVCUSERNAME as well
The end-user experience should be minimally changed. The most noticable effect will be that credential caches will not survive a reboot (this is a security enhancement, preventing a stolen system from being accessed for still-valid credentials).
This list is not (yet) complete:
Reverting to the original behavior will be possible, though non-trivial. Our current plan is to land this feature very early in the F18 process (some pieces are already landing today on 2012-02-23) so that we have the maximum amount of time to work out any issues.
- No relevant documentation