Description of problem: Happens on boot of current Rawhide live image. Prevents GNOME running unless you boot with enforcing=0. SELinux is preventing /usr/lib/systemd/systemd-logind from 'mounton' accesses on the directory . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-logind should be allowed mounton access on the 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 systemd-logind /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:systemd_logind_t:s0 Target Context system_u:object_r:user_tmp_t:s0 Target Objects [ dir ] Source systemd-logind Source Path /usr/lib/systemd/systemd-logind Port <Unknown> Host (removed) Source RPM Packages systemd-211-1.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-31.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.14.0-0.rc6.git1.1.fc21.x86_64 #1 SMP Tue Mar 11 13:14:48 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-03-12 20:50:11 EDT Last Seen 2014-03-12 20:50:11 EDT Local ID d031ba82-dd8e-413d-81b7-546867d0866b Raw Audit Messages type=AVC msg=audit(1394671811.153:161): avc: denied { mounton } for pid=691 comm="systemd-logind" path="/run/user/1000" dev="tmpfs" ino=20290 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir type=AVC msg=audit(1394671811.153:161): avc: denied { mount } for pid=691 comm="systemd-logind" name="/" dev="tmpfs" ino=20291 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem type=SYSCALL msg=audit(1394671811.153:161): arch=x86_64 syscall=mount success=yes exit=0 a0=7f09d87f3885 a1=7f09d8fe1a20 a2=7f09d87f3885 a3=6 items=0 ppid=1 pid=691 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-logind exe=/usr/lib/systemd/systemd-logind subj=system_u:system_r:systemd_logind_t:s0 key=(null) Hash: systemd-logind,systemd_logind_t,user_tmp_t,dir,mounton Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc6.git1.1.fc21.x86_64 type: libreport
Proposing as an Alpha blocker: "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop." https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_image_boot_behavior
Description of problem: After Updating to systemd-211-1.fc21.x86_64, gdm fails to start. While gdm starts, this issue happens. 1. Update to systemd-211-1.fc21 2. reboot gdm fails to start. 3. systemctl gdm.service gdm fails to start. Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc6.git0.1.fc21.x86_64 type: libreport
I can confirm that; `dmesg -l err` returns: systemd-gpt-auto-generator[350]: Out of memory. Furthermore, this issue, as expected with systemd, is affecting users on other distros as well with the upgrade to systemd-211; as indicated in the bugreport on https://bugs.freedesktop.org/show_bug.cgi?id=76058
If system is booted with kernel parameters `selinux=0`, gdm starts; though, after some time I received another avc-denial message SELinux is preventing /usr/lib/systemd/systemd-logind from 'unmount' accesses on the directory . as well as 'read' and 'rmdir' access.
Am I wrong in my assessment that this is an issue with systemd-211-1 package, and not necessarily with the selinux-policy?
Might be related to bug 1075288 and QUOTE:support for the Discoverable Partitions Specification. This enables systemd to automatically discover and mount/enable root, swap, /srv, and /home partitions during boot, simply by looking at the GPT partition table.:QUOTE The release-notes(?) are on https://plus.google.com/115547683951727699051/posts/5p1QuhdFtjN
Description of problem: yum upgrade Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc5.git1.1.fc21.x86_64 type: libreport
Description of problem: Rebooted, got this error, gdm displayed a black screen, setenforce 0 and service gdm restart made me able to login again Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc6.git0.2.fc21.x86_64 type: libreport
Description of problem: Updating to selinux-policy-targeted-3.13.1-31.fc21 prevents GDM from being launched successfully. The requires adding "enforcing=0" to the kernel boot options. There are other nine alerts now related to systemd-login which probably would not add substantial information if reported too. Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc6.git2.2.fc21.x86_64 type: libreport
This is probably due to systemd's new feature of mounting separate tmpfs runtime directories for each user under /run/user/. When this is fixed, please also consider merging it so f20's selinux-policy because it makes testing newer systemd releases pretty annoying. :-) The following SELinux module fixes it for me (it was created by audit2allow and is probably not optimal): module logind 1.0; require { type user_tmp_t; type systemd_logind_t; type user_tmpfs_t; type tmpfs_t; class capability sys_admin; class dir { read remove_name write mounton }; class filesystem { mount unmount }; } #============= systemd_logind_t ============== allow systemd_logind_t self:capability sys_admin; allow systemd_logind_t tmpfs_t:dir remove_name; allow systemd_logind_t tmpfs_t:dir { read write }; allow systemd_logind_t tmpfs_t:filesystem { mount unmount }; allow systemd_logind_t user_tmp_t:dir mounton; allow systemd_logind_t user_tmpfs_t:dir read;
Description of problem: System failed to stard gnome login screen, so I switched VT, setenforce 0, killall gnome-session and login screen came up. After logging in this selinux alert poped up. Additional info: reporter: libreport-2.2.0 hashmarkername: setroubleshoot kernel: 3.14.0-0.rc6.git3.2.fc21.x86_64 type: libreport
I tried to apply the patch in comment 10 to http://kojipkgs.fedoraproject.org//work/tasks/3736/6633736/Fedora-Live-Jam-KDE-x86_64-rawhide-20140314.iso, but could not quite figure out the syntax. Specifically, I 1. Booted from a USB containing a dd of the DVD 2. Used TAB key to add a 3 at the end of the boot line 3. Hit Enter to boot 4. When login prompt appeared, CTRL-ALT-F2 and logged in as root. 5. Did a . ./in, where file in contained: "semodule -i logind <<EOF require { type user_tmp_t; type systemd_logind_t; type user_tmpfs_t; type tmpfs_t; class capability sys_admin; class dir { read remove_name write mounton }; class filesystem { mount unmount }; } #============= systemd_logind_t ============== allow systemd_logind_t self:capability sys_admin; allow systemd_logind_t tmpfs_t:dir remove_name; allow systemd_logind_t tmpfs_t:dir { read write }; allow systemd_logind_t tmpfs_t:filesystem { mount unmount }; allow systemd_logind_t user_tmp_t:dir mounton; allow systemd_logind_t user_tmpfs_t:dir read; EOF" 6. And I got: "semodule: Failed on logind!"
Appears fixed with selinux-policy-3.13.1-36.fc21.noarch from the 20140315 updates.
Got it today with selinux-policy-targeted-3.13.1-71.fc21.noarch in an Xfce live build with some added packages and scripts. If the problem persists in the following days, I'll try building just Xfce as distributed in permissive mode, then add packages a few at a time until the problem reappears. I also got lines like "/etc/selinux/targeted/contexts/files/file_contexts: line 476 has invalid context system_u:object_r:condor_conf_t:s0 /etc/selinux/targeted/contexts/files/file_contexts: line 487 has invalid context system_u:object_r:kmscon_conf_t:s0 /etc/selinux/targeted/contexts/files/file_contexts: line 610 has invalid context system_u:object_r:git_content_t:s0 /etc/selinux/targeted/contexts/files/file_contexts: line 750 has invalid context system_u:object_r:abrt_var_lib_t:s0" that livecd-creator cut off at 10 messages before exiting to the chroot shell. I saw no such messages in today's Xfce build at https://kojipkgs.fedoraproject.org//work/tasks/8296/7258296/root.log . I think I can also get more information by starting with enforcing=0, issuing a setenforce 1, and trying unsuccesfully to login in another tty. I hope to get messages like the ones in the description of this bug.