#3548 KCM: klist fails with error: klist: Matching credential not found while listing ccache collection
Closed: Fixed 4 years ago by jhrozek. Opened 6 years ago by lslebodn.

I use sssd-kcm with two REALMS. But I get to the state where default ccache refers to UUID which does not exist. I hit this a month ago as well. I have no idea how it could happen. But maybe it could be related to hight IO or almost full disk. (it is just my suspicion).

But the main problem is that kerberos is unusable in such state

 sh-4.4$ echo $UID
1000
sh-4.4$ klist -l
klist: Matching credential not found while listing ccache collection
sh-4.4$ kdestroy -A
kdestroy: Matching credential not found while listing credential caches
sh-4.4$ klist -l
klist: Matching credential not found while listing ccache collection
sh# ldbsearch -H /var/lib/sss/secrets/secrets.ldb -b cn=1000,cn=persistent,cn=kcm dn
# record 1
dn: cn=ccache,cn=1000,cn=persistent,cn=kcm

# record 2
dn: cn=49a92d20-2105-4239-bac9-3f019c2eef67-1000:27785,cn=ccache,cn=1000,cn=persistent,cn=kcm

# record 3
dn: cn=default,cn=1000,cn=persistent,cn=kcm

# returned 3 records
# 3 entries
# 0 referrals
  • UUID of default ccache
sh# curl -H "Content-Type: application/octet-stream" -XGET --output - --unix-socket /var/run/secrets.socket http://localhost/kcm/persistent/1000/default
03990ac2-3b90-4c52-b4a6-541fde89d4b9 sh#

log files related to command: "klist -l"

I think we should not fail if we get erro [1432158218]: No credentials available
default ccache

just for the record. Existing ccache is for FEDORAPROJECT.ORG which was not default one

sh# curl -H "Content-Type: application/octet-stream" -XGET --output - --unix-socket /var/run/secrets.socket http://localhost/kcm/persistent/1000/ccache/49a92d20-2105-4239-bac9-3f019c2eef67-1000:27785 | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2619  100  2619    0     0   2619      0  0:00:01 --:--:--  0:00:01 2557k
{
    "version": 1,
    "kdc_offset": 0,
    "principal": {
        "type": 0,
        "realm": "FEDORAPROJECT.ORG",
        "components": [
            "lslebodn"
        ]
    },

And my workaround was do delete problematic reference to default ccache:

sh# curl -H "Content-Type: application/octet-stream" -XDELETE --unix-socket /var/run/secrets.socket http://localhost/kcm/persistent/1000/default
<html>
<head>
<title>200 OK</title></head>
<body>
<h1>OK</h1>
<p>Success</p>

and then klist at least can work

sh-4.4$ klist -l
Principal name                 Cache name
--------------                 ----------
lslebodn@FEDORAPROJECT.ORG     KCM:1000:27785 (Expired)

I agree that if we can't find the default cache, we should fallback and I thought we already had code that fell back to using the first cache as a safe default (this is an idea I copied from Heimdal-KCM). But maybe the fallback doesn't work well in this particular case..

Metadata Update from @jhrozek:
- Issue priority set to: major
- Issue set to the milestone: SSSD 1.16.1

6 years ago

Metadata Update from @lslebodn:
- Issue tagged with: KCM

6 years ago

Metadata Update from @jhrozek:
- Issue tagged with: postpone-to-1-16-2

6 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.2 (was: SSSD 1.16.1)

6 years ago

Metadata Update from @jhrozek:
- Issue untagged with: postpone-to-1-16-2

6 years ago

Since we are near the 1.16.2 release and this ticket has no PR yet, it will slip into 1.16.3.

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.3 (was: SSSD 1.16.2)

5 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.4 (was: SSSD 1.16.3)

5 years ago

After quite some time, I was able to reproduce this - if the secrets write fails for some reason (it happened on a very slow beaker VM), then we can get to the state where the UUID points to a cache that does not exist.

Metadata Update from @jhrozek:
- Issue tagged with: PR

5 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.2 (was: SSSD 1.16.4)

5 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.3 (was: SSSD 2.2)

4 years ago

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

4 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/4574

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