Description of problem: start boinc-client.service SELinux is preventing boinc from read, write access on the chr_file nvidia-uvm. ***** Plugin device (91.4 confidence) suggests **************************** If you want to allow boinc to have read write access on the nvidia-uvm chr_file Then you need to change the label on nvidia-uvm to a type of a similar device. Do # semanage fcontext -a -t SIMILAR_TYPE 'nvidia-uvm' # restorecon -v 'nvidia-uvm' ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that boinc should be allowed read write access on the nvidia-uvm 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: # ausearch -c 'boinc' --raw | audit2allow -M my-boinc # semodule -X 300 -i my-boinc.pp Additional Information: Source Context system_u:system_r:boinc_t:s0 Target Context system_u:object_r:device_t:s0 Target Objects nvidia-uvm [ chr_file ] Source boinc Source Path boinc Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.4-39.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.3.7-301.fc31.x86_64 #1 SMP Mon Oct 21 19:18:58 UTC 2019 x86_64 x86_64 Alert Count 4 First Seen 2019-11-10 10:29:00 PST Last Seen 2019-11-10 10:29:01 PST Local ID 4e3743a5-7177-47e7-981a-98c7821ca446 Raw Audit Messages type=AVC msg=audit(1573410541.187:333): avc: denied { read write } for pid=7608 comm="boinc" name="nvidia-uvm" dev="devtmpfs" ino=23821 scontext=system_u:system_r:boinc_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0 Hash: boinc,boinc_t,device_t,chr_file,read,write Version-Release number of selected component: selinux-policy-3.14.4-39.fc31.noarch Additional info: component: selinux-policy reporter: libreport-2.10.1 hashmarkername: setroubleshoot kernel: 5.3.7-301.fc31.x86_64 type: libreport
Hi, It looks like the target file had incorrect label and therefore the access was blocked. The label can be restored with a command like this: # restorecon -v /dev/nvidia-uvm provided the path is correct. As the path was not logged, you should check it on your system. Unfortunately, a change like this won't persist system reboot. Are you aware of any changes made to your system, either related to SELinux configuration or nvidia settings or other which would effect the current state?
Hi, I'm using nvidia nonfree driver provided in rpmfusion. Would it cause any problem? Thank you
Hi, This may be the reason, basically it depends on how the device creation is handled. This is the default context: # matchpathcon /dev/nvidia-uvm /dev/nvidia-uvm system_u:object_r:xserver_misc_device_t:s0 It is set for any pattern matching: /dev/nvidia.* but file transitions are defined only for an enumerated list of filenames. Is there any problem with using the software, or is it just the AVC denial you are concerned about? Is running the restorecon command a suitable workaround for you?
commit 98ceff40097850d9775fb9be21f98298d0cb9006 (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Thu Jan 30 13:29:00 2020 +0100 Add file transition for /dev/nvidia-uvm BZ(1770588)
FEDORA-2020-4824687c8c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4824687c8c
selinux-policy-3.14.4-46.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4824687c8c
selinux-policy-3.14.4-46.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.