Bug 2009245

Summary: SSSD doesn't reuse krb ccache when it is expected to.
Product: Red Hat Enterprise Linux 8 Reporter: Steeve Goveas <sgoveas>
Component: sssdAssignee: Tomas Halman <thalman>
Status: NEW --- QA Contact: sssd-qe
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.5CC: aboscatt, atikhono, grajaiya, lslebodn, mzidek, pbrezina, sbose, tscherf
Target Milestone: rcKeywords: Reopened, Triaged
Target Release: ---Flags: atikhono: needinfo? (aboscatt)
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-03-30 07:28:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.