Dear fellow developers,
with the upcoming Fedora 18 release (currently Rawhide) we are going to
change the place where krb5 credential cache files are saved by default.
The new default for credential caches will be the /run/user/<username>
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.
We have opened bugs to change the default location in libkrb5
https://bugzilla.redhat.com/show_bug.cgi?id=796429 in sssd
https://bugzilla.redhat.com/show_bug.cgi?id=786957 and nfs-utils
Normal users should not experience issues once these components are
fixed, however because the /run/user/<username> directory is created by
PAM it means this directory is not normally created for daemons that may
run as a system user.
One such case is mod_auth_kerb that recently gained the ability to kinit
with an HTTP/ keytab in order to support the s4u2proxy feature.
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 snipppet 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
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
If you have any questions feel free to contact any of the people in CC.
Stephen Gallagher * Red Hat, Inc * Massachusetts
I've noticed some strange soft lockup behaviour on my system (please
see the attachment). Soft lockup appears to be caused by kswapd0
process. It seems to me that in both cases this error occured when I
used "git fsck --full" or "git gc" commands.
On Thu, 2012-02-23 at 12:59 -0700, Stephen John Smoogen wrote:
> On 23 February 2012 12:28, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> > Dear fellow developers,
> > with the upcoming Fedora 18 release (currently Rawhide) we are going to
> > change the place where krb5 credential cache files are saved by default.
> > The new default for credential caches will be the /run/user/<username>
> > directory.
> I am going to ask something probably obvious but not what I could
> easily google. The sssd can be configured to cache tickets for a
> weekend or such in this case. The usage we usually ran into was:
> 1) Users can only log into laptops if able to communicate with AD/KRB
> servers or if a valid local ticket still existed.
> 2) User would turn off laptop and go home.
> 3) User would work from home and get a refreshed/new ticket when they
> got the VPN up. [If they didn't.. then they could not log in again
> after the ticket expired.]
This is just plain wrong. If that was happening, it was a bug in SSSD.
If we can't reach the Kerberos server, we'd authenticate against the
local cache (assuming that cached_credentials = True in sssd.conf). If
they also have krb5_store_password_if_offline = True, then the
credentials should automatically be updated when the VPN comes up as
well. (In the interim, we generate a fake credential cache file that
contains tickets that expired at the start of the epoch, so that
krb5-auth-dialog or manual kinit and the like will behave
The current validity status of the Kerberos ticket is completely
irrelevant to successful login. For the record, I've been
using /run/user/sgallagh/krb5cc for over a month now, and I've never
once had an issue authenticating with my cached credentials while
logging in at home, nor have I had an issue with the automatic deferred
kinit updating my tickets when I VPN in.
> In the Linux side the existance of a ticket in /tmp allowed this to
> work... but not sure how it would work in current environment.
> The above is probably "broken" in various ways that I don't know.. but
> was how a couple large work places had been set up.