Description of problem: This occurred after connecting to the VPN, during deferred kinit. This error was spotted in SSSD logs: [1137]: systemd-login gave error 13: Permission denied From SSSD sources: #ifdef HAVE_SYSTEMD_LOGIN ret = (uid, 0, NULL); if (ret > 0) { *result = true; return EOK; } if (ret == 0) { *result = false; } if (ret < 0) { DEBUG(SSSDBG_CRIT_FAILURE, "systemd-login gave error %d: %s\n", -ret, strerror(-ret)); } /* fall back to the old method */ #endif So it looks like something changed in the SELinux policy (selinux-policy-3.12.1-106.fc20.noarch) that no longer allows SSSD to call sd_uid_get_sessions() from systemd. SELinux is preventing /usr/libexec/sssd/sssd_be from 'search' accesses on the directory users. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sssd_be should be allowed search access on the users directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sssd_be /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:sssd_t:s0 Target Context system_u:object_r:systemd_logind_var_run_t:s0 Target Objects users [ dir ] Source sssd_be Source Path /usr/libexec/sssd/sssd_be Port <Unknown> Host (removed) Source RPM Packages sssd-common-1.11.90-0.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 Alert Count 3 First Seen 2013-12-20 16:39:47 EST Last Seen 2014-01-02 07:45:05 EST Local ID f8a4350b-5892-48b4-ad28-2f4a06819ae0 Raw Audit Messages type=AVC msg=audit(1388666705.492:556): avc: denied { search } for pid=1137 comm="sssd_be" name="users" dev="tmpfs" ino=15852 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=dir type=SYSCALL msg=audit(1388666705.492:556): arch=x86_64 syscall=open success=no exit=EACCES a0=7f5a8891f630 a1=80000 a2=1b6 a3=0 items=0 ppid=1131 pid=1137 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=sssd_be exe=/usr/libexec/sssd/sssd_be subj=system_u:system_r:sssd_t:s0 key=(null) Hash: sssd_be,sssd_t,systemd_logind_var_run_t,dir,search Additional info: reporter: libreport-2.1.10 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport
47642ee3a372a15289423b16c934ffe3e32ca184 fixes this in git. Although I don't see anywhere where we ever allowed it.
Actually, you're right. I forgot I had a custom build of SSSD enabled that is testing some newer systemd capabilities. This is an older feature that had not been used by default. It's still good to fix this now, though. I'm going to be recommending that we build with these features enabled in upcoming releases.
Ok Miroslav make sure we get it into RHEL7 policy ...
selinux-policy-3.12.1-116.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-116.fc20
Package selinux-policy-3.12.1-116.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 selinux-policy-3.12.1-116.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-116.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.