Default libkrb5 ccache location

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/26/2013 10:48 AM, Simo Sorce wrote:
> Recently a number of bugs [1-5] have come up regarding the new
> default Kerberos Ccache location that we changed according to [6].
> 
> We originally thought that reusing the same directory used by 
> XDG_USER_DIR was a good idea as systemd/logind would pre-create it
> for us and we'd all be happy.
> 
> Unfortunately it turns out there a re a number of cases where the 
> directory is not pre-created for us (sshd, sudo, su) and a number
> of cases where even if we created it out of systemd/logind
> supervision we'd risk it being yanked from under the process that
> is using it as by default systemd/logind uses a refcount system to
> know when to remove it.
> 
> I have an idea that can solve the problem relatively easily. Create
> a small dbus program (reuse oddjob ?) that will be called by 
> libkrb5 to request creation of the credential cache. This would be
> a small Fedora19 patch to libkrb5, I do not think upstream would
> like it in this form (more on it later)[*].
> 
> The dbus program would simply get the unix cred structure of the
> calling application via dbus services and unconditionally create
> /var/kerberos/user/%uidnumber/krbcc[**] directory based exclusively
> on the uid number of the peer and a system configured template, it
> would also create a symlink in /run/user/%uidnumber/krbcc for
> backwards compatibility in Fedora 19 only, and we transition 
> completely to the new dir in F20.
> 

I'm CCing Lennart and Kay on the discussion about this. Creating this
symlink in the oddjob would be somewhat error-prone. I'd rather that
we ask logind to carry a patch just for F19 where the creation of
XDG_RUNTIME_DIR would include this symlink.

I think this would be better behavior, since if the /run/user/UID
directory doesn't exist before we create our new
/var/kerberos/user/%uidnumber/krbcc version then the symlink won't be
created and cannot be recognized later if the /run/user/UID directory
appears.

Lennart/Kay, would that be an acceptable hack for you (just within F19)?


> Why a new dir ? Because we do not want systemd/logind to yank the 
> directory under us. There are a number of cases where it would be 
> beneficial to keep it around (example a cron job that starts every
> 10 minutes and uses cached credentials valid for hours to do some
> task).
> 
> 
> Simo.
> 
> [1] https://bugzilla.redhat.com/961235 - Credential cache directory
> /run/user/0/krb5cc does not exist [2]
> https://bugzilla.redhat.com/977972 - kinit: Credential cache 
> directory /run/user/0/krb5cc does not exist while getting default
> ccache [3] https://bugzilla.redhat.com/904720 -
> ipa-adtrust-install fails unexpectedly [4]
> https://bugzilla.redhat.com/796429 - sssd and kerberos should
> change the default location for create the Credential Caches to
> /run/usr/USERNAME/krb5cc [5] https://bugzilla.redhat.com/987792 -
> KRB5CCNAME is not set in PAM session with GSSAPI SSH auth [6]
> https://fedoraproject.org/wiki/Features/KRB5CacheMove
> 
> [*] I asked the MIT Kerberos team a while ago if we can make the
> cache type pluggable or revive the project to build a KCM (Kerberos
> Cache Manager) so we could decide to implement the cache manager
> functionality later, and there is interest. So that would be my
> long term strategy.
> 
> [**] I am flexible about where the dir should reside, if we want to
> keep tmpfs behavior we can put it under /run/kerberos/user
> 

I'd prefer to keep the tmpfs-by-default behavior because it prevents
the theft of credentials from a stolen hard drive. Users can always
modify the location they want to use by using the KRB5CCNAME
environment variable and various configuration options (such as
krb5_ccname_template in SSSD) to select a persistent location if they
choose to.


For the record, I like this plan. It should also serve to address a
number of unfortunate edge-cases, particularly those around the
semi-sessions created by 'su' and 'sudo'.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHyjzAACgkQeiVVYja6o6PaFQCeLV7z4OETe6Ghm5NRRMhOOpy7
SCcAnRxRSId/uo5u59MWgUjPtcPEMA78
=b9ET
-----END PGP SIGNATURE-----