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
(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
(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.
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.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
(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.
(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 # /etc/tmpfiles.d/sssd-kcm-remove-secrets.conf # 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.
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 ?
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
This seems to be corresponding upstream ticket: https://github.com/SSSD/sssd/issues/3593
(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.
> 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.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This continues to happen in Fedora 32. Florian, can you update version?
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.