[SSSD] [PATCH] KRB5: Recover gracefully if the ccache file could not be reused

Jakub Hrozek jhrozek at redhat.com
Mon Sep 24 13:55:39 UTC 2012


On Mon, Sep 24, 2012 at 12:35:50PM +0200, Sumit Bose wrote:
> On Sun, Sep 23, 2012 at 11:12:30PM +0200, Jakub Hrozek wrote:
> > https://fedorahosted.org/sssd/ticket/1384
> > 
> > I tested by logging in from one terminal, then chowning the ccache to
> > root.root to make the existing ccache unusable by the krb5_child process
> > and attempting to log in from another terminal.
> > 
> > Without the patch, the second login would just fail. With the patch, the
> > second login would succeed so the user can su or sudo and fix the
> > permissions problem.
> 
> But I would expect that it will only succeed if you use a ccache file
> with a random component. And since we use FILE:%d/krb5cc_%U_XXXXXX as a
> default this is good. But I think we should make clear that if e.g you
> use FILE:%d/krb5cc_%U or a DIR type ccache, which will most likely have
> a fixed location, the second login will still fail.
> 
> It would be nice if a check for the random component can be added here
> so that if we already know that we cannot overwrite the existing
> file or directory we fail before a new ticket is requested from the KDC.
> 
> If we really want to be able to allow logins even in this case the only
> solution I can think of is to generate a new ccache location with a
> random component based on the configured one, e.g. by adding a suffix
> like '_sssd_fallback_XXXXXX', and send a message back to the user via
> PAM which indicates this change and that the original localtion must be
> checked.
> 
> bye,
> Sumit

DIR cache might still work in case only the real ccache is not readable
but the file called "default" that points to the currently used ccache
is still accessible. But in general you are right.

We discussed this patch off-list some more with Sumit and he proposed
that we push this fix for 1.9.0 and improve the behaviour more in 1.9.1.
To do so, I filed:
https://fedorahosted.org/sssd/ticket/1533



More information about the sssd-devel mailing list