+++ This bug was initially created as a clone of Bug #1031154 +++ Description of problem: The new keyring type "big_key" operates based on a threshold. If it exceeds a certain size, instead of using kernel memory it will open a kernel tmpfs file and store the credentials in that. This triggers an AVC with SSSD's krb5_child process (and presumably any other user process attempting to use the KEYRING cache type) if the user's TGT is large, such as when authenticating against an Active Directory domain. Version-Release number of selected component (if applicable): kernel-3.11.9-300.fc20.x86_64 How reproducible: Every time Steps to Reproduce: 1. Ensure that SELinux is in enforcing mode 2. Enroll the machine using 'realm join' to an Active Directory enterprise domain. 3. Attempt to log in via SSH, virtual terminal, etc. with an AD-provided user. Actual results: Login fails Expected results: Login should succeed. Additional info: AVC: type=AVC msg=audit(1384534121.329:472): avc: denied { write } for pid=2719 comm="krb5_child" path=2F202864656C6574656429 dev="tmpfs" ino=79801 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file
Proposed as a Blocker for 20-final by Fedora user sgallagh using the blocker tracking app because: Users that enroll a machine with an Active Directory or FreeIPA domain controller at install time may be unable to log in due to SELinux denials around the kernel big_key support. This behavior requires a large TGT such as would be received when authenticating with Active Directory either directly or via a FreeIPA trust or if authenticating against a FreeIPA domain with a large number of groups.
Discussed at 2013-11-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . This is obviously a bad bug if you're using remote auth, but the logic of the install process is such that you should never be locked out of the system: anaconda will not let you escape without setting a root password or creating a local user account with admin rights, so this bug should never cause you to be outright excluded from the system. Not being able to log in with the only user account (in the case you set a root password during install) is still bad, but remote auth is a somewhat 'advanced' use case and we'd expect anyone who hits this to be able to resolve it (or have it resolved by their IT folks), or workaround it with enforcing=0 . So this was rejected as a blocker, but accepted as a freeze exception issue, since it'd be good if we can fix it and so save anyone from having to work around it. But if we're going to take the change we'd like it to be soon, not very late in freeze.
Did the fix for this wind up in https://admin.fedoraproject.org/updates/FEDORA-2013-22531 ? If not, are we going to get the fix? Today's probably the last day we could pull it in safely.
(In reply to Adam Williamson from comment #3) > Did the fix for this wind up in > https://admin.fedoraproject.org/updates/FEDORA-2013-22531 ? If not, are we > going to get the fix? Today's probably the last day we could pull it in > safely. No, we're going to miss the boat on this one, sorry. Patches are being submitted upstream today, but we're not likely to make it in time for Fedora.
(In reply to Adam Williamson from comment #3) > Did the fix for this wind up in > https://admin.fedoraproject.org/updates/FEDORA-2013-22531 ? If not, are we > going to get the fix? Today's probably the last day we could pull it in > safely. Nope. The original bug has another patch submitted, but I haven't seen it submitted anywhere, including the distro the original bug is targeted at. I have no idea if that actually fixes the problem, or if it's an addition to the other patch in that bug. I'd be happy to get something in, if I knew what that something was.
Josh provided me with a scratch build tonight (http://koji.fedoraproject.org/koji/taskinfo?taskID=6257181) that I tested. I can confirm that the patch does eliminate the issue.
I've committed the changes and started an official build. Will file an update as soon as it completes.
kernel-3.11.10-301.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.10-301.fc20
Package kernel-3.11.10-301.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.10-301.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22818/kernel-3.11.10-301.fc20 then log in and leave karma (feedback).
kernel-3.11.10-301.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.12.5-301.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.12.5-301.fc20
kernel-3.12.5-302.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.