On a system using configured to use SSSD with LDAP as id_provider and
Krb5 as auth_provider, users cannot log in (via SSH) when the Linux
keyring is to be used as credential cache. The exact errors appearing in
syslog are:

***

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=127.0.0.1 user=johndoe

Credentials cache keyring 'persistent:12345:0' not found

Can't find client principal johndoe@MYREALM.COM in cache collection

pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=127.0.0.1 user=johndoe

pam_sss(sshd:auth): received for user johndoe: 4 (System error)
Failed password for johndoe from 127.0.0.1 port 22222 ssh2

***

This happens both when the ticket cache is configured globally
(default_ccache_name = KEYRING:persistent:%{uid} in
krb5.conf/[libdefaults]) and when it is told to use the keyring
specifically in sssd.conf (krb5_ccname_template = KEYRING:persistent:%U
in the right realm declaration).

Only sssd seems to be affected, command-line Kerberos tools such as
kinit happily use the keyring.

According to sssd-krb5(5) on the affected systems, the version of sssd
provided in Jessie should support using the keyring.

After reverting the credential cache to files in /tmp, Kerberos
authentication in sssd works correctly.


I use Debian Jessie (specifically, version 8.7) on amd64, kernel
3.16.39-1+deb8u2 and libc6 2.19-18+deb8u7.

Dear maintainers,

all Kerberos credential cache collections are unusable with sssd and the Debian kernel in Buster.

Details:

1) KEYRING:persistent fails to work since CONFIG_PERSISTENT_KEYRINGS is not set in the Kernel.
    Effectively, this yields a flaky (sometimes working, sometimes not) setup at runtime,
    since Kerberos falls back to the user keyring, and sssd-krb5's krb5_child and the
    kernel keyring garbage collector race.
    This is likely also one of the causes of #861222 (affects Jessie, in CC).
    Since the kernel option has been set to "yes" as of 5.5.17-1, I'm also CCing debian-kernel ML.

2) DIR:dirname fails since the directory is created by sssd-krb5 with broken permissions 0600.
    This has already been reported upstream in [0] by another user, but upstream recommended to use KEYRING:persistent
    instead, since DIR:dirname is not well tested.

3) KCM: fails with many or large tickets, as outlined in an upstream bug[1] only fixed in very recent sssd versions
    (>= 2.3) by a series of large patches.

I can open separate bugs on (1), (2) and (3) if wanted, but I imagine starting with an overview (since all collections are broken)
is a better starting point (and fixing a single one definitely lower severity).

On a side-note, cache collections are needed in case tickets for multiple realms are to be stored,
i.e. this issue affects any users working in multiple realms (and relying on SSSD).
Non-SSSD consumers can work around the issue by using (2).