Description of problem: SELinux is preventing /usr/bin/gnome-shell from read, write access on the chr_file rfkill. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that gnome-shell should be allowed read write access on the rfkill chr_file 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 gnome-shell /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:wireless_device_t:s0 Target Objects rfkill [ chr_file ] Source gnome-shell Source Path /usr/bin/gnome-shell Port <Unknown> Host (removed) Source RPM Packages gnome-shell-3.9.90-1.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-72.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.0-0.rc6.git0.1.fc20.x86_64 #1 SMP Mon Aug 19 14:05:11 UTC 2013 x86_64 x86_64 Alert Count 22 First Seen 2013-08-23 10:59:03 IDT Last Seen 2013-08-28 16:12:38 IDT Local ID c19be79f-4c11-4cdb-a4ee-ad3f2370f276 Raw Audit Messages type=AVC msg=audit(1377695558.345:204): avc: denied { read write } for pid=22274 comm="gnome-shell" name="rfkill" dev="devtmpfs" ino=10073 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:wireless_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1377695558.345:204): arch=x86_64 syscall=open success=no exit=EACCES a0=3816026e5c a1=2 a2=44f7140 a3=7fff988b6b00 items=0 ppid=22209 pid=22274 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 ses=4294967295 tty=(none) comm=gnome-shell exe=/usr/bin/gnome-shell subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: gnome-shell,xdm_t,wireless_device_t,chr_file,read,write Additional info: reporter: libreport-2.1.6 hashmarkername: setroubleshoot kernel: 3.11.0-0.rc6.git0.1.fc20.x86_64 type: libreport Potential duplicate: bug 996822
The latest git allows this.
Description of problem: It didn't seem related to me at first, but this AVC denial and the authentication problem ONLY happen together and I encountered this problem multiple times and it is easily reproducible: 1. Lock the Screen (GNOME Shell screen shield / curtain closes) (Super+L in my case, or the lock icon in the system menu) -> Curtain comes down, monitor turns black. 2. (Move mouse, press some key and ...) Pull up the curtain -> Password entry field blinks on and off, it is not possible to put in a password, and "Authentication failure" is displayed below. The only way to log back in is to click on "Login as another user" and login from GDM. When logged back in, the AVC denial pops up. Both problems _don't_ happen when GNOME Shell locks the screen by itself after the set time limit. Additional info: reporter: libreport-2.1.6 hashmarkername: setroubleshoot kernel: 3.11.0-rc7-fafadora type: libreport
I think the unable to login problem is not related to the SELinux issue. For some reason gdm is now touching the rfkill device, probably to manipulate the wireless system. The flickering login on the lock screen is not caused by this. When this happens on my box, I go to the console and login as root and then execute loginctl unlock-session SESSIONNUMBER
Description of problem: I attempted to unlock in gnome-shell with Fedora 20. The screen flashed repeated authentication failed errors. I selected "Log in as another user", then changed back to the first screen. The SELinux error appeared. Additional info: reporter: libreport-2.1.6 hashmarkername: setroubleshoot kernel: 3.11.0-0.rc7.git2.1.fc20.x86_64 type: libreport
(In reply to Daniel Walsh from comment #3) > I think the unable to login problem is not related to the SELinux issue. > For some reason gdm is now touching the rfkill device, probably to > manipulate the wireless system. The flickering login on the lock screen is > not caused by this. > > When this happens on my box, I go to the console and login as root and then > execute > > loginctl unlock-session SESSIONNUMBER The unable-to-login problem is a known systemd (logind) bug. It will be fixed once the systemd guys do a release, or someone brave enough will build systemd with the relevant patch for Fedora. Also, why re-assign the bug, when it's clearly a different bug?
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.