On Fri, 2013-07-26 at 11:01 -0400, Stephen Gallagher wrote: > 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'. I'd rather like to see a plan that would fix also other similar uses off /run/user/<uid> and not just the Kerberos. Unfortunately Lennart insists otherwise so I am afraid that this is doomed to fail and hacks like this one above will prevail. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
