What is wrong with this? The data that goes into keyring is the cleartext password. We need user cleartext creds from keyring only if we start offline and then get online. After that the creds are removed from the keyring (are they or we keep them forever?). If the system never gets online and reboots the new clear text password will be captured and stored.

So is this just the garbage collection?
I thought that only sssd can access the ring, is this not the case?
If it is not this seems to be different issue and IMO should be treated as a separate ticket related to protecting access to the keyring data. I has nothing to do with how many sessions we actually start.

Replying to [comment:1 dpal]:

What is wrong with this? The data that goes into keyring is the cleartext password. We need user cleartext creds from keyring only if we start offline and then get online. After that the creds are removed from the keyring (are they or we keep them forever?). If the system never gets online and reboots the new clear text password will be captured and stored.

This is a different use case, it is for when cifs.ko is using NTLM authentication instead of Kerberos authentication to transparently access windows shares.
In this case cifs.ko needs to be able to access creds at any time when online.

So is this just the garbage collection?

I don't understand the context of this question.

I thought that only sssd can access the ring, is this not the case?

cifs.ko is in kernel it can access the keyring if it wants/needs to.

If it is not this seems to be different issue and IMO should be treated as a separate ticket related to protecting access to the keyring data. I has nothing to do with how many sessions we actually start.

See above

1. First of all NTLM seems to be a corner case nowadays with 2003 AD already being 9 years old. I am not sure we should address it.
2. It is not clear from the decryption above what exactly we are solving.
   • It seems that we need to keep user password all the time even when user is not logged in. Why?
   • There are two problems mentioned in the original decryption: garbage collection and access to the password by root. It is unclear what the problems actually are. What garbage collection? Kernel discarding SSSD keyring during the SSSD restart? How does this work? And regarding root access to passwords, is it a problem that we can/need to address at all? The whole "password in clear for NTLM" use case seems very insecure and outdated. May be we should not do it at all.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10 beta
rhbz: => todo
summary: Access to cache credentials is lost on daemon restart => [RFE] Access to cache credentials is lost on daemon restart
type: defect => enhancement

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

mark: => 0

We spoke with Simo about NTLM auth and came up with a different idea. The named keyring might be nice to have but I'm inclined to defer the work.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => trivial
review: => 0

Mass-moving tickets not planned for any immediate release and re-setting priority.

milestone: SSSD 1.13 backlog => SSSD Deferred
priority: trivial => major

This will be solved by KCM.

blockedby: => 2887
sensitive: => 0

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2569

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.