Learn more about these different git repos.
Other Git URLs
MIT Kerberos allows for the creation of new credential-cache storage mechanisms, beyond the standard FILE and MEMORY types. This can be done with the {{{krb5_cc_register()}}} function.
SSSD should provide a socket-based interface to storing the user's credential cache in the SSSD's user-cache LDB file.
This would resolve many long-standing issues related to storage of credential caches in the /tmp directory, the most recent and visible being that it does not work with pam_namespace (which provides a per-session private /tmp directory).
I would propose that SSSD should register an SSS cache-storage type at startup and use this instead of a file-based cache by default (the option to use file-based caches should remain for backwards compatibility)
Fields changed
type: defect => enhancement
cc: dwalsh => dwalsh, tmraz
Will it allow having a CC cache per user per domain? So that same user but in two domains can have different caches? Does it solve the use following use case:
A machine is a part of domain A and user is a part of the same domain. But also from time to time user needs to log into a domain B with the same short user name. Like dpal@corp.com - domain A, and dpal@opensource.org - domain B.
Will this feature allow user to keep his CCes separate and not blow away the caches for principal dpal@corp.com when user authenticates against opensource.org? If it does I really want it in 1.5.
We had a conversation with Simo on the IRC and then on the phone. I was hoping that the the credential cache plugin would allow us to save multiple credentials in one place - SSSD and cerve back to kerberos library the right credential depending upon the situation the library is used in. Simo explained that unfortunately the library does not provide a hint to the plugin the environment in which the credential is going to be used thus it is impossible to decide which credential to return. We can do a trick and still support multiple credentials in a plugin and LDB but then there should be an external command utility that will tell SSSD which credential to return. We can track the connected process by socket and continue to return the right credentials to it after the utility was used to switch. So potentially we can support the case when two different apps use two different credentials stored in LDB at the same time. This however will not work for the web case well when one instance of the Firefox needs to access two different web sites and use different kerberos credentials from one process. The only way it will work is that the kerberos library itself would support handling multiple credentials at the same time. This is not the case now. I see this as a primary use case we actually want to solve. This answers my question from comment above. "No it will not help" to solve the problem of using different credentials for different realms. Thus it makes this a bit less attractive than I thought.
I think we should do what we already plan to do in 1.5. Put this into 1.6 bucket for now and reconsider if we have time.
milestone: NEEDS_TRIAGE => SSSD 1.6.0
owner: somebody => sgallagh
coverity: => priority: major => minor upgrade: => 0
We consider this to be a requirement for trust support.
milestone: SSSD 1.6.0 => SSSD 1.7.0 patch: => 0 priority: minor => critical
This has be re-evaluated. We might not take this rout as it does not add much value at least now.
milestone: SSSD 1.8.0 => SSSD Deferred
priority: critical => minor
Returning this to NEEDS_TRIAGE. It appears that the kernel keyring support is very limited and does not meet all of our needs.
(10:57:16 AM) simo: nalin, how big is the kernel quota ? (10:57:35 AM) simo: a cred cache can be really big indeed (10:58:02 AM) simo: It may be interesting a hybrid mode where we store in the keyring just the TGT (10:58:14 AM) simo: that should keep it reasonable contained ... (10:58:33 AM) simo: still could be > than 65k (10:58:38 AM) nalin: it's tunable, but kernel.keys.maxbytes = 20000 on my box (10:58:40 AM) sgallagh: And use the TGT to decrypt a file-based credcache? (10:58:55 AM) simo: nalin, then it's not usable (10:58:58 AM) simo: dwalsh, ^ (10:59:13 AM) simo: 20k is a way too low limit to store krb credcaches (10:59:23 AM) nalin: sgallagh: that sounds a bit complicated to me (10:59:32 AM) ***simo thinks we should just make sssd the cred store and use unix sockets to accs it (10:59:35 AM) simo: *access (10:59:47 AM) sgallagh: Yeah, I guess that has to be back on the table again (10:59:54 AM) simo: sgallagh, the problem is in keeping files around I think (10:59:59 AM) sgallagh: I didn't realize how limited the kernel cache was. 11:00 (11:00:33 AM) nalin: alls i know is what 'sysctl -a | grep ^kernel.keys' tells me (11:00:54 AM) sgallagh: are we sure that maxybytes is actually bytes and not kilobytes? (11:01:13 AM) simo: sgallagh, it's unlikely to be 20M pe ruser (11:01:20 AM) nalin: sgallagh: not at all (11:01:24 AM) simo: sgallagh, that's locked unswappable kernel memory (11:01:33 AM) nalin: sgallagh: though simo's probably right about that (11:01:35 AM) simo: (iirc) (11:01:56 AM) sgallagh: Yeah, just looked it up. It appears it is just bytes 11:05 (11:05:03 AM) dwalsh: I guess you can reopen my original bug...
milestone: SSSD Deferred => NEEDS_TRIAGE rhbz: =>
milestone: NEEDS_TRIAGE => SSSD 1.9.0 priority: minor => critical
blockedby: => blocking: => milestone: SSSD 1.9.0 => SSSD Kerberos improvemens
Needs to be re-evaluated in the context of #974 and GSSAPI proxy effort.
Per discussion with Simo. I will move it to deferred bucket.
milestone: SSSD 1.9.x Kerberos improvements => SSSD Deferred priority: critical => minor
rhbz: => 0
The original problem is solved in the MIT Kerberos code. MIT now provides ccache of type DIR which if being used by default in F18.
So now it makes sense to just close this issue.
feature_milestone: => proposed_priority: => Undefined resolution: => wontfix status: new => closed
Metadata Update from @sgallagh: - Issue assigned to sgallagh - Issue set to the milestone: SSSD Patches welcome
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/1694
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.