Description of problem: I resumed from suspend on F21 x86_64 (Workstation/GNOME desktop), and was unable to see a password entry field when I typed. The screenlock/shield did not change and I could not move it to get a password entry field. However, my typng was accepted and the screen was unlocked. SELinux is preventing login from read, write access on the chr_file /dev/dri/card0. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that login should be allowed read write access on the card0 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 login /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:local_login_t:s0-s0:c0.c1023 Target Context system_u:object_r:dri_device_t:s0 Target Objects /dev/dri/card0 [ chr_file ] Source login Source Path login Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-105.3.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.18.7-200.fc21.x86_64 #1 SMP Wed Feb 11 21:53:17 UTC 2015 x86_64 x86_64 Alert Count 16421 First Seen 2015-02-07 06:09:36 EST Last Seen 2015-03-11 11:10:13 EDT Local ID 0634e7d7-1cb2-4840-873c-3891a45aab2b Raw Audit Messages type=AVC msg=audit(1426086613.573:20098): avc: denied { read write } for pid=11596 comm="login" path="/dev/dri/card0" dev="devtmpfs" ino=11862 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0 Hash: login,local_login_t,dri_device_t,chr_file,read,write Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Any help here? Why login writing to /dev/dri/card0 ?
Do you really mean login(1) command? (So the text terminal/console login program.) Maybe the user is talking about xserver/gdm :-)
Ah, I see comm="login" in audit log... Well, I have no clue why it works with /dev/dri/card0, PAM or so?
Description of problem: I don't know how this problem happened, but I would place my bet on a leaked file descriptor from kmscon, which spawned login. I'm reporting this bug as a selinux bug through the tool, but most likely it's a kmscon issue. Version-Release number of selected component: selinux-policy-3.13.1-105.6.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.19.2-201.fc21.x86_64 type: libreport
Paul, if you add a local policy, does it help?
Since doing a fresh install on this machine (again, F21), I haven't been able to reproduce the problem. Maybe this was a bug elsewhere that's been fixed?
Probably, we can close this for now.
Sorry, but I've missed this report, why would you think this would have been related to kmscon (the userspace console ?) This isn't the default console in fedora, so it's quite surprising that kmscon would be involved at all. As per-the previous message, I'm closing now, but re-assigned to util-linux because of the login question.