-----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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
