+++ This bug was initially created as a clone of Bug #1669607 +++

Since the upgrade to Fedora 29, my Kerberos tickets no longer expire. They are kept in the cache indefinitely, it appears.

klist says:

Ticket cache: KCM:1000:512

So I believe sssd-kcm is in fact used. (I do not otherwise use sssd.) With Fedora 28, I used the kernel keyring, so I couldn't observe the issue there even if the bug was present. (This is not an update, but a new installation.)

This affects both FEDORAPROJECT.ORG tickets and REDHAT.COM tickets. Right now, I don't have any such lingering tickets, but I can run specific diagnostic steps tomorrow if you tell me what to watch out for.

(And I think that keeping session keys around for longer than necessary is a minor security risk.)

Seen with:

sssd-kcm-2.0.0-5.fc29.x86_64
krb5-libs-1.16.1-25.fc29.x86_64

— Additional comment from Lukas Slebodnik on 2019-01-26 12:15:00 UTC —

(In reply to Florian Weimer from comment #0)
> Since the upgrade to Fedora 29, my Kerberos tickets no longer expire. They
> are kept in the cache indefinitely, it appears.
>
> klist says:
>
> Ticket cache: KCM:1000:512
>
> So I believe sssd-kcm is in fact used. (I do not otherwise use sssd.) With
> Fedora 28, I used the kernel keyring, so I couldn't observe the issue there
> even if the bug was present. (This is not an update, but a new
> installation.)
>
sssd.service and sssd-kcm.service are two independent daemons which shares some common internal libraries.

> This affects both FEDORAPROJECT.ORG tickets and REDHAT.COM tickets. Right
> now, I don't have any such lingering tickets, but I can run specific
> diagnostic steps tomorrow if you tell me what to watch out for.
>
> (And I think that keeping session keys around for longer than necessary is a
> minor security risk.)
>

It is a nice idea to have an option for sssd-kcm to destroy tickets at the end of user session.
But on the other hand I like the feature that my ticket is available after reboot. (That was not possible with kernel keyring or with files in /tmp)

> Seen with:
>
> sssd-kcm-2.0.0-5.fc29.x86_64
> krb5-libs-1.16.1-25.fc29.x86_64

There is a simple way how to use KEYRING ccache if you want. You just need to modify configuration snippet provided by sssd-kcm package. Or you can even uninstall that package.

sh$ rpm -qf /etc/krb5.conf.d/kcm_default_ccache
sssd-kcm-2.0.0-6.fc30.x86_64

— Additional comment from Florian Weimer on 2019-01-26 20:12:05 UTC —

(In reply to Lukas Slebodnik from comment #1)

> > This affects both FEDORAPROJECT.ORG tickets and REDHAT.COM tickets. Right
> > now, I don't have any such lingering tickets, but I can run specific
> > diagnostic steps tomorrow if you tell me what to watch out for.
> >
> > (And I think that keeping session keys around for longer than necessary is a
> > minor security risk.)
> >
>
> It is a nice idea to have an option for sssd-kcm to destroy tickets at the
> end of user session.

That wouldn't make a difference in my case.

> But on the other hand I like the feature that my ticket is available after
> reboot. (That was not possible with kernel keyring or with files in /tmp)

A ticket that's expired has only value to a potential attacker. It can only be used to decrypt old data, new data will not be accepted by a peer (because it will observe that its version of the ticket is expired).

> There is a simple way how to use KEYRING ccache if you want. You just need
> to modify configuration snippet provided by sssd-kcm package. Or you can
> even uninstall that package.
>
> sh$ rpm -qf /etc/krb5.conf.d/kcm_default_ccache
> sssd-kcm-2.0.0-6.fc30.x86_64

Does this mean you do not consider this a bug? Thanks.

— Additional comment from Simo Sorce on 2019-01-27 17:25:55 UTC —

Florian,
it is generally not a bug.
In krb5, most ccache types do not actively remove expired tickets, until you kdestroy.
The keyring has a nice feature wherby you can make it forget keys automatically, and it also has a limitation on the quantity of data a user can store, so we used that feature. The fact old tickets were removed was just a nice side-effect, but the absence of that behavior is not a bug.
It may a nice feature though, so we could turn this bug into a RFE.

— Additional comment from Ben Cotton on 2019-08-13 16:57:35 UTC —

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

— Additional comment from Ben Cotton on 2019-08-13 19:33:13 UTC —

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

— Additional comment from Anthony Messina on 2019-10-27 18:41:09 UTC —

(In reply to Simo Sorce from comment #3)
> Florian,
> it is generally not a bug.
> In krb5, most ccache types do not actively remove expired tickets, until you
> kdestroy.
> The keyring has a nice feature wherby you can make it forget keys
> automatically, and it also has a limitation on the quantity of data a user
> can store, so we used that feature. The fact old tickets were removed was
> just a nice side-effect, but the absence of that behavior is not a bug.
> It may a nice feature though, so we could turn this bug into a RFE.

The "nice side-effect" also allowed KRB/NFS mounted /home directories (with gssproxy) to work properly since the ccache was always clean after a reboot. At this point, sssd-kcm integration with gssproxy and nfs-utils is troublesome at best. To login to a freshly booted workstation (KDE/SDDM), I need to login Ctrl+F2, login to the console (where it tells me I don't have access to my /home directory), then kdestroy -A && kinit, Ctrl+F1, then login via SDDM. I'm considering (for specific workstations) mounting over /var/lib/sss/secrets with a temporary directory to restore the old "nice side-effect" of starting from scratch on every reboot.

— Additional comment from Anthony Messina on 2019-10-27 19:10:20 UTC —

(In reply to Anthony Messina from comment #6)
> (In reply to Simo Sorce from comment #3)
> > Florian,
> > it is generally not a bug.
> > In krb5, most ccache types do not actively remove expired tickets, until you
> > kdestroy.
> > The keyring has a nice feature wherby you can make it forget keys
> > automatically, and it also has a limitation on the quantity of data a user
> > can store, so we used that feature. The fact old tickets were removed was
> > just a nice side-effect, but the absence of that behavior is not a bug.
> > It may a nice feature though, so we could turn this bug into a RFE.
>
> The "nice side-effect" also allowed KRB/NFS mounted /home directories (with
> gssproxy) to work properly since the ccache was always clean after a reboot.
> At this point, sssd-kcm integration with gssproxy and nfs-utils is
> troublesome at best. To login to a freshly booted workstation (KDE/SDDM), I
> need to login Ctrl+F2, login to the console (where it tells me I don't have
> access to my /home directory), then kdestroy -A && kinit, Ctrl+F1, then
> login via SDDM. I'm considering (for specific workstations) mounting over
> /var/lib/sss/secrets with a temporary directory to restore the old "nice
> side-effect" of starting from scratch on every reboot.

The following synthesizes startup/reboot with empty ccaches for everyone/everything

1. /etc/tmpfiles.d/sssd-kcm-remove-secrets.conf
2. Remove sssd-kcm secrets database on boot
   r! /var/lib/sss/secrets/secrets.ldb

With the above, after a reboot:

1. The first time I login via SDDM, sddm-helper fails with: chdir( /home/user1 ) failed for user: "user1", verify directory exist and has sufficient permissions
2. I am returned to the login screen
3. The second time I login via SDDM, it works properly

It seems the first go-round initializes the KCM: ccache with the nfs/sever@REALM ticket, which is then "ready" for the second login attempt.

It's likely none of this is helpful, but wanted to log end-user usability issues with the default Fedora setup with sssd-kcm, gssproxy, nfs-utils.

— Additional comment from Orion Poplawski on 2020-06-01 21:40:43 UTC —

I'm not sure the non-removal of expired ticket is directly related to the NFS issues, or if it more of an issue how KCM handles cache collections in general. Is this just another manifestation of https://github.com/SSSD/sssd/issues/4988 ?

— Additional comment from Fedora Admin user for bugzilla script actions on 2020-06-18 14:59:25 UTC —

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

— Additional comment from Pavel Březina on 2020-07-08 13:03:17 UTC —

This seems to be corresponding upstream ticket:
https://github.com/SSSD/sssd/issues/3593

— Additional comment from Florian Weimer on 2020-07-08 13:08:18 UTC —

(In reply to Pavel Březina from comment #10)
> This seems to be corresponding upstream ticket:
> https://github.com/SSSD/sssd/issues/3593

It's perhaps related, but slightly different. Expired tickets are only useful to attackers, so there's absolutely no reason to keep them around. Purging tickets on session end might impact some workflows negatively.

— Additional comment from Robbie Harwood on 2020-07-08 17:35:38 UTC —

> Expired tickets are only useful to attackers, so there's absolutely no reason to keep them around.

That's... more reductionist than I think is accurate.

krb5 does change behavior based on the presence of tickets, expired or no. For instance, consider a collection with credentials for REDHAT.COM and IPA.REDHAT.COM (in that order). For hostname.redhat.com, the credential for REDHAT.COM will typically be preferred, even if it's expired. Pruning the credential for REDHAT.COM will cause the one for IPA.REDHAT.COM to be used instead. In that case, pruning is desirable (and for this reason, Simo has been in favor of it I believe).

However, consider instead the same setup with REDHAT.COM and FEDORAPROJECT.ORG. Pruning expired REDHAT.COM will cause FEDORAPROJECT.ORG's credential to be attempted. While this will obviously not work (no cross realm there), the errors will be confusing to a user who doesn't realize the REDHAT.COM credential has been expired (and there's nothing krb5 can do about it because the ccache expired it out from under us). And it's potentially even more confusing when cross-realm relationships come into play.

Upstream's position is that the second case is more typical, so in-tree ccache backends (FILE, DIR, MEMORY, etc.) do not prune. KEYRING prunes.