Bug 2009245 - SSSD doesn't reuse krb ccache when it is expected to. [NEEDINFO]
Summary: SSSD doesn't reuse krb ccache when it is expected to.
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Halman
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-30 08:57 UTC by Steeve Goveas
Modified: 2023-08-14 08:27 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-03-30 07:28:22 UTC
Type: Bug
Target Upstream Version:
Embargoed:
atikhono: needinfo? (aboscatt)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-98566 0 None None None 2021-09-30 10:37:13 UTC
Red Hat Issue Tracker SSSD-4059 0 None None None 2021-10-21 08:38:53 UTC

Description Steeve Goveas 2021-09-30 08:57:35 UTC
Description of problem:

TGT active / not active:
In 8.4:
```
28802]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_2001_LI2HRD] and is not active and TGT is  valid.
28802]] [k5c_precreate_ccache] (0x4000): Recreating ccache
```
In 8.5:
```
29437]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_2001_dd3Df6] and is  active and TGT is  valid.
```
  --  this is immediate reason old ccache isn't deleted


Version-Release number of selected component (if applicable):
sssd-2.5.2-2.el8

How reproducible:
always

Steps to Reproduce:
https://gitlab.cee.redhat.com/sssd/sssd-qe/-/blob/RHEL8.5/client/krb_provider/krb_tgt_renewal/tgt_renewal#L3

Actual results:
1. Old ccache is not deleted
2. tgt is active with no active session


Expected results:
If old session is active old ccache should be updated and not create a new one


Additional info:

Comment 1 Alexey Tikhonov 2021-09-30 11:50:57 UTC
To elaborate a bit:

(In reply to Steeve Goveas from comment #0)
> Description of problem:
> 
> TGT active / not active:
> In 8.4:
> 28802]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_2001_LI2HRD] and is not active and TGT is  valid.
> 28802]] [k5c_precreate_ccache] (0x4000): Recreating ccache
>
> In 8.5:
> 29437]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_2001_dd3Df6] and is  active and TGT is  valid.
> 
> Steps to Reproduce:
> https://gitlab.cee.redhat.com/sssd/sssd-qe/-/blob/RHEL8.5/client/
> krb_provider/krb_tgt_renewal/tgt_renewal#L3
> 
> Actual results:
> 1. Old ccache is not deleted
> 2. tgt is active with no active session
> 
> 
> Expected results:
> If old session is active old ccache should be updated and not create a new
> one


Mentioned tests expects: there is no active session => krb5_child should delete old ccache and create new one

There are two issues observed:
1) `check_if_uid_is_active()` returns incorrect result ("Ccache_file is ... is  active")
this should force SSSD to re-use this cache and then
2) SSSD creates a new ccache (when it is expected that old ccache should be reused)

I propose to use this BZ to track item (2). For this we need a new test that ensures there *is* an active user session to force code path that should re-use ccache.

Perhaps we need additional BZ to track (1)

Comment 2 Alexey Tikhonov 2021-10-07 14:10:41 UTC
Looks very similar to bz 1991704

Comment 3 Alexey Tikhonov 2021-11-16 14:28:25 UTC
(In reply to Alexey Tikhonov from comment #1)
> 
> There are two issues observed:
> 1) `check_if_uid_is_active()` returns incorrect result ("Ccache_file is ...
> is  active")
> this should force SSSD to re-use this cache and then
> 2) SSSD creates a new ccache (when it is expected that old ccache should be
> reused)
> 
> I propose to use this BZ to track item (2). For this we need a new test that
> ensures there *is* an active user session to force code path that should
> re-use ccache.
> 
> Perhaps we need additional BZ to track (1)

for item (1) - bz 2012263

Comment 5 RHEL Program Management 2023-03-30 07:28:22 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


Note You need to log in before you can comment on or make changes to this bug.