Default libkrb5 ccache location

[Simo Sorce]

On Fri, 2013-07-26 at 11:01 -0400, Stephen Gallagher wrote:
> -----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.

Ah yeah this would be even better.

> 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.

Admins can also add a tempfiles.d script to create a symlink to a stable
location only for those user's they want to keep a permanent location.

So I am fine with tmpfs.

> 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'.

Yep.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York