#3873 Perform some basic ccache initialization as part of gen_new to avoid a subsequent switch call failure
Opened 14 days ago by jhrozek. Modified 4 days ago

Ticket was cloned from Red Hat Bugzilla: Bug 1645291

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:
This is more or less copy-n-paste from an e-mail discussion I had with Robbie

I was looking into one issue triggered by OpenSSH with Jakub Jelen and
I think I need your help about behaviour of the difference ccache
types in krb5.

The reproducer for this issue is to log in with SSH's built-in
Kerberos authentication (not PAM). Then, SSH internally manages the

There are only two calls that even concern the ccache before the issue
appears. First, openssh calls krb5_cc_new_unique() which calls into
kcm_gen_new(). Next, openssh calls krb5_cc_switch(), which calls into
kcm_switch_to() on the krb5 side.

And here is what I'm confused about -- looking at the libkrb5 code,
calling gen_new with other ccaches (I took DIR as an example) also
creates the ccache, but not with KCM.

If you look at dcc_gen_new() then it calls verify_dir() which actually
creates the DIR structure. The other call to verify_dir() in the dir
ccache code is in dcc_resolve(). This makes sense to me.

However, looking at the kcm ccache code, kcm_gen_new only invokes the
KCM_OP_GEN_NEW operation of the KCM deamon. And both the Heimdal KCM
implementation and the SSSD KCM implementation of the KCM_OP_GEN_NEW
just generate a new unique ID for the subsidiary cache and return it.
There is no initialization involved in KCM_OP_GEN_NEW. The only time
KCM deamon initializes the cache is when it receives the
KCM_OP_INITIALIZE operation and looking at the MIT KCM ccache code,
the KCM_OP_INITIALIZE operation is only invoked through the
kcm_initialize() ccache method.

So what I'm not sure about is -- is it expected that gen_new doesn't
create the ccache "storage"? Why does it do that with dir and other
ccaches? Should the KCM deamon initialize the ccache with

And Robbie's response:
Alright, so upstream and I talked a bit about this, and it's a deficiency in the KCM protocol.

KCM_OP_INITIALIZE requires a principal to initialize the ccache to. This means that, from the krb5 side, we can't actually send an OP_INITIALIZE message because we don't have a principal in mind at the time krb5_cc_new_unique (and therefore gen_new) is called.

My recommendation would be to perform some initialization on receipt of KCM_OP_GEN_NEW - at least enough that a subsequent KCM_OP_SET_DEFAULT_CACHE (i.e., krb5_cc_switch) won't cause a match failure.

Reassigning to SSSD as there's unfortunately nothing krb5 can do here that I can see.

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1645291

14 days ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.1

4 days ago

Login to comment on this ticket.