 |
Another user experienced a similar problem: Not sure reporter: libreport-2.1.11.1 hashmarkername: setroubleshoot kernel: 3.10.0-1127.el7.x86_64 package: selinux-policy-3.13.1-266.el7.noarch reason: SELinux is preventing /usr/sbin/smartd from 'read' accesses on the chr_file nvme0. reproducible: Not sure how to reproduce the problem type: libreport |
|
|
Another user experienced a similar problem: Revently installed new SSD at /dev/nvme0 $ ls -lZ /dev/nvme* crw-------. root root system_u:object_r:nvme_device_t:s0 /dev/nvme0 brw-rw----. root disk system_u:object_r:nvme_device_t:s0 /dev/nvme0n1 Smartd should be allowed to read this device. Note: Device not yet partiioned and nothing installed on it. Just plugged in and did some tests to interrogate controller. ---------- Generated a local policy module to allow this access by executing: # ausearch -c 'smartd' --raw | audit2allow -M my-smartd # semodule -i my-smartd.pp reporter: libreport-2.1.11.1 hashmarkername: setroubleshoot kernel: 3.10.0-1160.53.1.el7.x86_64 package: selinux-policy-3.13.1-268.el7_9.2.noarch reason: SELinux is preventing /usr/sbin/smartd from 'read' accesses on the chr_file nvme0. reproducible: Not sure how to reproduce the problem type: libreport |
|
|
Confirm the problem still exists: - selinux-policy-3.13.1-268.el7_9.2 - selinux-policy-targeted-3.13.1-268.el7_9.2 I've resolved the problem by repeating several times: ausearch -c 'smartd' --raw | audit2allow -M my-smartd && semodule -i my-smartd.pp && systemctl restart smartd Finally I've got following my-smartd.te: module my-smartd3 1.0; require { type fsdaemon_t; type nvme_device_t; class blk_file { ioctl open read }; class chr_file { ioctl open read }; } #============= fsdaemon_t ============== #!!!! This avc is allowed in the current policy allow fsdaemon_t nvme_device_t:blk_file { ioctl open read }; allow fsdaemon_t nvme_device_t:chr_file ioctl; #!!!! This avc is allowed in the current policy allow fsdaemon_t nvme_device_t:chr_file { open read }; |
- Anonymous
