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

[Jakub Hrozek]

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.

[Sumit Bose]

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
> From da9151e73d6389705463341728bc0fbef4982900 Mon Sep 17 00:00:00 2001
> From: Jakub Hrozek 
> Date: Sun, 23 Sep 2012 23:00:45 +0200
> Subject: [PATCH] KRB5: Recover gracefully if the ccache file could not be
>  reused
> https://fedorahosted.org/sssd/ticket/1384
>
> src/providers/krb5/krb5_utils.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/providers/krb5/krb5_utils.c b/src/providers/krb5/krb5_utils.c
> index 8b15fc35dd172179713eac53fc2d4aa20f229d28..774f62dad092f54e979f887307b72f6ccdc4acbf 100644
> --- a/src/providers/krb5/krb5_utils.c
> +++ b/src/providers/krb5/krb5_utils.c
> @@ -721,8 +721,9 @@ cc_file_check_existing(const char *location, uid_t uid,
>  ret = cc_residual_is_used(uid, filename, SSS_KRB5_TYPE_FILE, &active);
>  if (ret != EOK) {
>    DEBUG(SSSDBG_OP_FAILURE, ("Could not check if ccache is active\n"));
>    return ret;
>    DEBUG(SSSDBG_OP_FAILURE, ("Could not check if ccache is active. "
>                              "Will create a new one.\n"));
>    active = false;
>
> }
>
> kerr = krb5_init_context(&context);
>
> @@ -890,8 +891,9 @@ cc_dir_check_existing(const char *location, uid_t uid,
>      ret = cc_residual_is_used(uid, dir, SSS_KRB5_TYPE_DIR, &active);
>      talloc_free(tmp);
>      if (ret != EOK) {
>    DEBUG(SSSDBG_CRIT_FAILURE, ("Could not check if ccache is active\n"));
>    return ret;
>    DEBUG(SSSDBG_OP_FAILURE, ("Could not check if ccache is active. "
>                              "Will create a new one.\n"));
>    active = false;
>
> }
>
> krberr = krb5_init_context(&context);
>
> -- 
> 1.7.11.4
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Jakub Hrozek]

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

[Jakub Hrozek]

On Mon, Sep 24, 2012 at 03:55:39PM +0200, Jakub Hrozek wrote:
> 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

Pushed to master.