#3413 a bug in libkrb5 causes kdestroy -A to not work with more than 2 principals with KCM
Closed: Invalid 11 months ago by jhrozek. Opened 2 years ago by jhrozek.

I'm not sure if this is a bug in our sssd-kcm implementation or in libkrb5, but IIRC I was able to also reproduce it with Heimdal's KCM server, so it might be a bug in libkrb5. Needs more work.

To reproduce:

[root@client ~]# kinit alice
Password for alice@IPA.TEST: 
[root@client ~]# klist 
Ticket cache: KCM:0
Default principal: alice@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:06  05/30/2017 10:38:03  krbtgt/IPA.TEST@IPA.TEST
[root@client ~]# kinit bob
Password for bob@IPA.TEST: 
[root@client ~]# klist -A
Ticket cache: KCM:0:12783
Default principal: bob@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:16  05/30/2017 10:38:13  krbtgt/IPA.TEST@IPA.TEST

Ticket cache: KCM:0
Default principal: alice@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:06  05/30/2017 10:38:03  krbtgt/IPA.TEST@IPA.TEST
[root@client ~]# kinit carol
Password for carol@IPA.TEST: 
[root@client ~]# klist -A
Ticket cache: KCM:0:87402
Default principal: carol@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:27  05/30/2017 10:38:24  krbtgt/IPA.TEST@IPA.TEST

Ticket cache: KCM:0
Default principal: alice@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:06  05/30/2017 10:38:03  krbtgt/IPA.TEST@IPA.TEST

Ticket cache: KCM:0:12783
Default principal: bob@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:16  05/30/2017 10:38:13  krbtgt/IPA.TEST@IPA.TEST
[root@client ~]# kdestroy 
[root@client ~]# klist -A
Ticket cache: KCM:0
Default principal: alice@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:06  05/30/2017 10:38:03  krbtgt/IPA.TEST@IPA.TEST

Ticket cache: KCM:0:12783
Default principal: bob@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:16  05/30/2017 10:38:13  krbtgt/IPA.TEST@IPA.TEST
[root@client ~]# kdestroy -A
[root@client ~]# klist 
Ticket cache: KCM:0:12783
Default principal: bob@IPA.TEST

Valid starting       Expires              Service principal
05/29/2017 10:38:16  05/30/2017 10:38:13  krbtgt/IPA.TEST@IPA.TEST

The last kdestroy should have destroyed all ccaches, but bob's remain.


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

2 years ago

Metadata Update from @jhrozek:
- Issue priority set to: critical

2 years ago

Metadata Update from @jhrozek:
- Issue tagged with: cleanup-one-sixteen

2 years ago

Metadata Update from @jhrozek:
- Issue untagged with: cleanup-one-sixteen
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

2 years ago

Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1

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

2 years ago

Hum, this issue also looks like it could possibly be relevant to an issue I'm seeing in openQA FreeIPA testing with Fedora 27 (using the KCM cache by default):

https://bugzilla.redhat.com/show_bug.cgi?id=1421604#c13

lukas, does this happen only with KCm cache collection? Or does it happen with Keyring as well ?

(Sorry for answering for Lukas, I'm sure he will chime in if he has any tests he did on his own)

When I hit the issue some months ago when initially working on KCM, this happened only with KCM, not with KEYRING, but on the other hand, the issue was also reproducable with the KCM server from Heimdal (tested on Debian). That's why I suspected the bug might be on the krb5-libs side, but since then, I didn't have any time to work on the bug.

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

2 years ago

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

2 years ago

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

2 years ago

Metadata Update from @fidencio:
- Issue assigned to fidencio

2 years ago

In the end it's an issue on krb5 side and here's a PR for them: https://github.com/krb5/krb5/pull/755

I'll close this issue when the PR gets merged there.

Okay, PR got merged to krb5 and I've opened https://github.com/SSSD/sssd/pull/546 for SSSD in order to add the tests back. I'll only close this PR when the tests are added back to our code.

Metadata Update from @fidencio:
- Custom field patch adjusted to on

2 years ago

First, this was not a bug in SSSD, so I think this ticket can be closed. Second, adding tests might not be trivial since we would have to rebuild krb5 in our CI, but even then users who run unpatched krb5 might see tests failing.

In the meantime, moving to a later milestone with a trivial priority and renaming the issue.

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

2 years ago

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

a year ago

Metadata Update from @fidencio:
- Assignee reset

a year ago

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

11 months ago

Login to comment on this ticket.

Metadata