Red Hat Bugzilla – Bug 914433
sssd pam write_selinux_login_file creating the temp file for SELinux data failed
Last modified: 2013-11-21 17:14:57 EST
Description of problem: After updating to sssd-1.9.2-82.el6.x86_64 tonight IPA registered users can not login. Version-Release number of selected component (if applicable): sssd-1.9.2-82.el6.x86_64 Red Hat Enterprise Linux Server release 6.4 (Santiago) How reproducible: Always Steps to Reproduce: 1. try to ssh as an IPA registered user Actual results: $ ssh xyz Connection closed by 10.20.117.146 Expected results: $ ssh xyz Last login: Fri Feb 22 09:44:36 2013 from 10.92.217.89 Additional info: sssd_pam.log: (Fri Feb 22 10:02:14 2013) [sssd[pam]] [write_selinux_login_file] (0x0040): creating the temp file for SELinux data failed. /etc/selinux/targeted/logins/maxAYGyki(Fri Feb 22 10:02:14 2013) [sssd[pam]] [pam_reply] (0x0100): blen: 40
Created attachment 701109 [details] sssd_pam.log
What version of selinux-policy do you have installed?
Selinux is disabled: # getenforce Disabled # sestatus SELinux status: disabled
The workaround would be to put SELinux into permissive mode. SSSD is a security software. It is recommended to run with SELinux on. This is how it is developed and tested. Permissive mode is the compromise. If it does not work in the permissive mode then this is a real issue which we would look into.
Is the directory /etc/selinux/targeted/logins/ there at all? What permissions does it have?
*** Bug 914428 has been marked as a duplicate of this bug. ***
Directory /etc/selinux/targeted does not exist. # ls -l /etc/selinux total 12 -rw-r--r-- 1 root root 113 Jan 16 14:15 restorecond.conf -rw-r--r-- 1 root root 76 Jan 16 14:15 restorecond_user.conf -rw-r--r-- 1 root root 2271 Oct 15 14:08 semanage.conf It used to work just yesterday with selinux disabled. Is there a way to make it work again with selinux disabled please? I am loath to enable it because it used to break our proprietary applications or cause other nasty issues.
Can you check if mkdir -p /etc/selinux/targeted/logins/ fixes the issue for you?
It does, thanks a lot Jakub.
We still need to fix the problem in SSSD. We should either detect if SELinux is off completely and skip creating the context or just check if the logins directory exists before attempting to write the file there.
Upstream ticket: https://fedorahosted.org/sssd/ticket/1817
btw I think SELinux should always create the directory and just ignore potential contents, so I filed https://bugzilla.redhat.com/show_bug.cgi?id=915811
Just in case, https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html never mentions SELinux as a requirement for either IPA server or client.
Maxim, can you chime in to bug #915811 and describe how exactly you installed your system? Was selinux disabled from anaconda? Do you have selinux-policy-targeted installed at all?
Fixed upstream.
Verified using ipa-server-3.0.0-37.el6.x86_64, ipa-client-3.0.0-37.el6.x86_64, sssd-1.9.2-128.el6.x86_64, selinux-policy-3.7.19-218 On server: # sestatus SELinux status: disabled installed ipa-server # ls -l /etc/selinux/ total 20 -rw-r--r--. 1 root root 457 Oct 11 08:29 config -rw-r--r--. 1 root root 113 Sep 18 12:43 restorecond.conf -rw-r--r--. 1 root root 76 Sep 18 12:43 restorecond_user.conf -rw-r--r--. 1 root root 2271 Oct 15 2012 semanage.conf drwxr-xr-x. 6 root root 4096 Oct 8 15:35 targeted_ORIG On client: # sestatus SELinux status: disabled # ls -l /etc/selinux/ total 20 -rw-r--r--. 1 root root 457 Oct 11 09:06 config -rw-r--r--. 1 root root 113 Sep 18 12:43 restorecond.conf -rw-r--r--. 1 root root 76 Sep 18 12:43 restorecond_user.conf -rw-r--r--. 1 root root 2271 Oct 15 2012 semanage.conf drwxr-xr-x. 6 root root 4096 Oct 8 15:17 targeted_ORIG installed client Then from client ssh'd as an ipa user to server: # ssh admin@<ipa server name> Was successful
That's great, thank you gents!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1680.html