acer-predator-turbo-and-rgb-keyboard-linux-module icon indicating copy to clipboard operation
acer-predator-turbo-and-rgb-keyboard-linux-module copied to clipboard

facer.ko and SELinux

Open x211321 opened this issue 6 months ago • 0 comments
trafficstars

Hi everyone,

some distros come with SELinux enabled by default as is the case with fedora, where I reinstalled the module today after a while of inactivity.

I remember having some SELinux related trouble in the past when installing the module. Back then I could resolve those issues by setting the file context for facer.ko via semanage fcontext and chcon.

semanage fcontext -a -t modules_object_t /opt/turbo-fan/src/facer.ko
chcon -t modules_object_t /opt/turbo-fan/src/facer.ko

I have to admit I understand very little about SELinux and its workings, to the point that I have only a vague idea about what those two commands actually accomplish.

I might misremember how I got it working in the past but in any case today I couldn't get my system to load facer.ko via the systemd service no matter what I tried.

It would load without issue when I ran /opt/turbo-fan/service.sh directly but when executed via turbo-fan.service insmod src/facer.ko failed every time.

Via journalctl I found that SELinux was blocking the module from being loaded.

journalctl --no-pager -b -g "avc.*insmod"

AVC avc: denied { module_load } for pid=185225 comm="insmod" path="/opt/turbo-fan/src/facer.ko" dev="nvme1n1p3" ino=6278052 scontext=system_u:system_r:kmod_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=system permissive=1

In the end I could only get it to run by temporately disabling SELinux before loading the module and re-enabling it afterwards.

/opt/turbo-fan/service.sh

...
setenforce 0
insmod src/facer.ko
setenforce 1
...

I assume this is not the recommended way of handling situations like this but with my limited SELinux understanding its the best I could come up with.

Is this a common issue for users that use distros that come with SELinux by default?

Does anyone know of a better way to handle this situation besides disabling SELinux temporately or permanently?

I don't know how often users stumble upon this issue but maybe it would be worth mentioning somewhere in the README or during install? (Assumed that this is actually a common issue and not just my own ineptitude.)

Kernel: 6.14.5-200.fc41.x86_64 Distro: Fedora Linux 41 Device: Nitro AN515-45

x211321 avatar May 09 '25 21:05 x211321