#3873 Perform some basic ccache initialization as part of gen_new to avoid a subsequent switch call failure
Closed: Fixed 2 years ago by jhrozek. Opened 2 years ago by jhrozek.

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
ccache.

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
KCM_OP_GEN_NEW?

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

2 years ago

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

2 years ago

A related bugzilla ticket which I don't believe is private: https://bugzilla.redhat.com/show_bug.cgi?id=1607082

I had added some logs there but it sounds like the issue is relatively well understood.

Metadata Update from @jhrozek:
- Issue assigned to jhrozek

2 years ago

Metadata Update from @jhrozek:
- Issue tagged with: KCM, PR, bug

2 years ago

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4863

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata