Description of problem: Please add /dev/nvidia0 and /dev/nvidiactl to /etc/selinux/restorecond.conf for nvidia vga user. # matchpathcon /dev/nvidia0/dev/nvidia0 system_u:object_r:xserver_misc_device_t:s0 # ls -Z /dev/nvidia0 crw-rw-rw-. root root system_u:object_r:device_t:s0 /dev/nvidia0 # restorecon -R -v /dev/nvidia0 restorecon reset /dev/nvidia0 context system_u:object_r:device_t:s0->system_u:object_r:xserver_misc_device_t:s0 # matchpathcon /dev/nvidiactl /dev/nvidiactl system_u:object_r:xserver_misc_device_t:s0 # ls -Z /dev/nvidiactl crw-rw-rw-. root root system_u:object_r:device_t:s0 /dev/nvidiactl # restorecon -R -v /dev/nvidiactl restorecon reset /dev/nvidiactl context system_u:object_r:device_t:s0->system_u:object_r:xserver_misc_device_t:s0 bug 94918, comment 1 is difficult task for End User to resolve the issue. Version-Release number of selected component (if applicable): 2.0.86 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: See bug 94918 comment 1
Sorry, my mistake. bug 694918, comment 1
Well it should work in F16 without restorecond. what does # rpm -q selinux-policy show
(In reply to comment #2) > Well it should work in F16 without restorecond. > > what does > > # rpm -q selinux-policy > > show $ rpm -q selinux-policy selinux-policy-3.10.0-18.fc16.noarch
and you end up with /dev/nvidia0 labeled as device_t always? This is strange.
What process is creating these devices?
maybe one could determine what is creating these files by adding the following line to /etc/audit/audit.rules -a exit,always -F path=/dev/nvidiact -F perm=rwxa make sure audit is enabled and reboot. attach /var/log/audit/audit.log and hopefully we can see what is creating it....
(In reply to comment #5) > What process is creating these devices? Well, I guess it is their Xorg server module that creates those /dev entries via inotify() as long as their kernel module does nothing special but register_chrdev() completely bypassing kobject infrastructure. So, it seems that proper restorecond configuration currently is the only way to set the correct security labels.
I also confirm that as of 07-NOV-11 this nasty bug persists in Fedora 16
closing as a dup, fixed in selinux-policy-3.10.0-52.fc16.noarch *** This bug has been marked as a duplicate of bug 748069 ***