Created attachment 351487 [details] actual selinux alert Description of problem: external mrtg scripts are not allowed to run due to selinux policy Version-Release number of selected component (if applicable): selinux-policy-3.6.12-62.fc11.noarch selinux-policy-targeted-3.6.12-62.fc11.noarch How reproducible: Always Steps to Reproduce: 1. Enable external scripts in mrtg.conf 2. mrtg is being run with 5 minuted intervals (crontab) 3. selinux errors appear Actual results: SELinux errors messages stating: SELinux is preventing mrtg (mrtg_t) "execute" mrtg_etc_t. the scripts are not run. Expected results: Working scripts, no access denied errors Additional info: The files in /etc/mrtg are currently set to: [kramer@nasng mrtg]$ ll -Z -rwx------. root root system_u:object_r:mrtg_etc_t:s0 cpufan_speed.sh -rwx------. root root system_u:object_r:mrtg_etc_t:s0 cpu_temp.sh -rwx------. root root system_u:object_r:mrtg_etc_t:s0 fan_speed.sh -rwx------. root root system_u:object_r:mrtg_etc_t:s0 hdd_temp.sh -rwx------. root root system_u:object_r:mrtg_etc_t:s0 mb_temp.sh -rw-r--r--. root root system_u:object_r:mrtg_etc_t:s0 mrtg.cfg -rwx------. root root system_u:object_r:mrtg_etc_t:s0 nbfan_speed.sh
Did you create thise files? If you chcon -t bin_t /etc/mrtg/*.sh It should work. Arese these files packages somewhere?
Reassigning to mrtg to get their comments on this. Should these files be placed somewhere else? Does the documentation suggest that these files be created here? If yes could we change the it to /etc/mrtg/scripts and then add the scripts directory to the rpm?
Yes, I created these files. The feed mrtg with info needed. I've changed the context of the .sh files. Now I no longer get the selinux alerts with the access denied messages. However I now seem to get a new error (see attachment 2 [details]), it pop up every 5 minutes (mrtg is run every five minutes). What is a good way to stream line this for mrtg? Maybe create a mrtg bin directory which can hold all scripts and create a accompanying selinux policy? Of course this only when bin_t is the proper context. The files now look like: [kramer@nasng mrtg]$ ll -Z -rwx--x--x. root root system_u:object_r:bin_t:s0 cpufan_speed.sh -rwx--x--x. root root system_u:object_r:bin_t:s0 cpu_temp.sh -rwx--x--x. root root system_u:object_r:bin_t:s0 fan_speed.sh -rwx--x--x. root root system_u:object_r:bin_t:s0 hdd_temp.sh -rwx--x--x. root root system_u:object_r:bin_t:s0 mb_temp.sh -rw-r--r--. root root system_u:object_r:mrtg_etc_t:s0 mrtg.cfg -rw-r--r--. root root system_u:object_r:mrtg_etc_t:s0 mrtg.cfg~ -rwx--x--x. root root system_u:object_r:bin_t:s0 nbfan_speed.sh
Created attachment 351621 [details] new console helper selinux alert new console helper selinux alert, after changing *.sh context to bin_t. Occurs every 5 mins.
I suggest to place your own mrtg scripts to /usr/local/bin/.
(In reply to comment #2) > Reassigning to mrtg to get their comments on this. Should these files be > placed somewhere else? Does the documentation suggest that these files be > created here? If yes could we change the it to /etc/mrtg/scripts and then add > the scripts directory to the rpm? These files were created by user, mrtg package doesn't contain scripts (except of examples in /usr/share/doc/mrtg-%{version}). /etc/mrtg is for configuration files only.
Jurgan looks like you are executing some binary that is linked to a userhelper application? /usr/bin/consolehelper-gtk What are you trying to do with this?
The selinux alert regaring console helper stopped appearing after I logged of and logged in again. But now I have a new message telling me hddtemp is not allow to read /dev/sda. I will first move my mrtg scripts to /usr/local/bin and will file a separate bug is the problem persists.
OK, I've moved the scripts to /usr/local/bin. Only the hddtemp selinux alert remains. This is / was also the source of the consolehelper messages as /usr/bin/hddtemp is linked to consolehelper. (the real program resides in /usr/sbin, but when I directly call hddtemp in /usr/sbin I get consolehelper-gtk messages). Will file in a separate bug -> bug #512997. I think this bug can now be closed.