On 01/31/2017 10:24 AM, Jan Kurik wrote:
= System Wide Change: Kerberos KCM credential cache by default = https://fedoraproject.org/wiki/Changes/KerberosKCMCache Change owner(s): * Jakub Hrozek <jhrozek AT redhat DOT com> Default to a new Kerberos credential cache type called KCM which is better suited for containerized environments and provides a better user experience in the general case as well. == Detailed Description == Over time, Fedora used different credential cache types to store Kerberos credentials - going from a simple file-based storage (FILE:) to a directory (DIR:) and most recently a kernel-keyring based cache (KEYRING:). Each of these caches has its own set of advantages and disadvantages. The FILE ccache is very widely supported, but does not allow multiple primary caches in a collection. The DIR cache does, but creating and managing the directories including proper access control can be tricky. The KEYRING cache is not well suited for cases where multiple semi-isolated environments might share the same kernel. Managing credential caches' life cycle is not well solved in neither of these cache types automatically, only with the help of a daemon like SSSD. The scope of this change is to introduce a new Kerberos credential cache type called KCM and switch to using it by default. With KCM, the Kerberos caches are not stored in a "passive" store, but managed by a daemon. In this setup, the Kerberos library (typically used through an application, like for example, kinit) is a "KCM client" and the daemon is being referred to as a "KCM server". The KCM server will be provided as a socket-activated service of the SSSD deamon. == Scope == * Proposal owners: SSSD developers will implement a KCM server. The krb5-libs package will then switch its default from KEYRING to KCM. The libkrb5 package will require the sssd-kcm subpackage and enable its socket so that the KCM server is socket activated when needed. Please note that the KCM server only listens on a local UNIX socket, not over the network.
I'm concerned about a low-level library package like krb5-libs depending on a higher-level package like sssd-ksm, and possible dependency cycles it could create. Also, updating the default config in krb5-libs won't update people who have edited their krb5.conf.
Could the same thing be accomplished by having sssd-ksm drop the required config into /etc/krb5.conf.d/, installing sssd-ksm via Workstation comps, and skipping the package-level dependencies entirely?
* Other developers: None required * Release engineering: None required * List of deliverables: None affected * Policies and guidelines: None required * Trademark approval: N/A (not needed for this Change)
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
