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
# 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):
Steps to Reproduce:
See bug 94918 comment 1
Sorry, my mistake.
bug 694918, comment 1
Well it should work in F16 without restorecond.
# rpm -q selinux-policy
(In reply to comment #2)
> Well it should work in F16 without restorecond.
> what does
> # rpm -q selinux-policy
$ rpm -q selinux-policy
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 ***