Description of problem: This morning, I upgraded to the latest kernel available in the Rawhide repositories. Immediately thereafter, I started getting permission denied errors when trying to authenticate using my Kerberos credentials through SSSD. I did some debugging and discovered that the permission denials are coming from the kernel keyring. The problem was not present in kernel-4.5.0-0.rc0.git1.1.fc24 and manifested in kernel-4.5.0-0.rc0.git5.1.fc24. (There were no other successful builds in Koji between 1.1 and 5.1, so I cannot narrow the problem down any further. Version-Release number of selected component (if applicable): kernel-4.5.0-0.rc0.git5.1.fc24 and later kernel-4.5.0-0.rc0.git5.1.fc24 How reproducible: Every time Steps to Reproduce: 1. Configure a system with SSSD to authenticate using Kerberos 2. Attempt to log in "online" (not using cached credentials for disconnected operation) Actual results: Authentication fails, logs show permission-denied errors coming from the kerberos library credential cache operations. Expected results: Authentication should succeed. Additional info:
Proposed as a Blocker for 24-alpha by Fedora user sgallagh using the blocker tracking app because: Alpha criterion: "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
I took a closer look at the Koji builds and saw that kernel-4.5.0-0.rc0.git3.1.fc24 built successfully for x86_64, so I installed that version. It worked properly, which means that the issue must have been introduced between 3.1 and 5.1. Looking at the things that changed between those two versions, I'd hazard a guess that the commit that introduced it is probably http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?id=42aa4321c736d85b027e9cf2e595db174b3cc76b
I can confirm the issue, exactly as sgallagh describes, and I'm +1 blocker.
As an incomplete workaround, one can add krb5_ccname_template = FILE:/tmp/krb5cc_%U_XXXXXX to the [domain/DOMAINNAME] section of sssd.conf and then run ldbedit -H /var/lib/sss/db/cache_DOMAINNAME.ldb and delete any line starting with 'ccacheFile` This will switch back to using the old /tmp file-based approach to credential caches. This is not a good long-term solution as it doesn't play well with poly-instantiated /tmp or multiple-TGT setups. Or you can do what I'm doing and hold the kernel back at a working version until this is fixed.
(In reply to Stephen Gallagher from comment #2) > Looking at the things that changed between those two versions, I'd hazard a > guess that the commit that introduced it is probably > http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/ > ?id=42aa4321c736d85b027e9cf2e595db174b3cc76b There's nothing in that commit that would have an effect that I can see. The only keyring-related thing is specific to asymmetric keys and IMA - neither of which should be involved here.
(In reply to David Howells from comment #5) > (In reply to Stephen Gallagher from comment #2) > > Looking at the things that changed between those two versions, I'd hazard a > > guess that the commit that introduced it is probably > > http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/ > > ?id=42aa4321c736d85b027e9cf2e595db174b3cc76b > > There's nothing in that commit that would have an effect that I can see. > The only keyring-related thing is specific to asymmetric keys and IMA - > neither of which should be involved here. You need to look more closely. That's a typical rawhide git snapshot commit. Which means the bulk of the change isn't in flat files in Fedora git. It's in the snapshot patch itself. If git5.1 is the commit that introduces the problem, that corresponds with upstream commit 5807fca, and if git4.1 doesn't show the problem, that corresponds to upstream commit 7d1fc01. There are almost 3000 commits upstream between those two points. Namely among them are the security tree merge, which includes all the key patches.
Doing a successful kinit followed by a kdestroy shows: kdestroy: Operation not permitted while destroying cache Ticket cache NOT destroyed! which appears to be related to the problem.
The problem is in upstream commit 1d6d167c2efcfe9539d9cffb1a1be9c92e39c2c0 where the application of KEY_FLAG_KEEP is made unconditional.
You can test this with: keyctl newring foo @s keyctl add user a a %:foo keyctl unlink %user:a %:foo keyctl clear %:foo The last two commands fail with the unfixed kernel, but all the commands should work.
Created attachment 1118644 [details] Patch to revert the change that caused the problem
This patch has been applied to kernel-4.5.0-0.rc1.git0.2.fc24 (building now) If you could test with this kernel once the build completes and let us know, I would appreciate it.
(In reply to Justin M. Forbes from comment #11) > This patch has been applied to kernel-4.5.0-0.rc1.git0.2.fc24 (building now) > If you could test with this kernel once the build completes and let us know, > I would appreciate it. Tested and working!