You are not allowed to use this action.

Clear message

    PaulHowarth/Blog/2008-05-20

Tuesday 20th May 2008

Fedora Project

According to Bug #447247, spamass-milter won't start in Fedora 9. So I tested it and it was true! :-(

The dæmon started but died straight away. There was no obvious reason for it, but by following the hit the bug reporter gave that it might be something to do with writing the PID file, I guessed it might be an SELinux issue. This was confirmed when I did a setenforce 0 to go into permissive mode and found that the service started without problems. There were no AVCs so whatever the problem was must have been dontaudit-ed in policy. So I turned off the dontaudit rules and tried restarting the service: 

# semodule -DB
# service spamass-milter restart

This revealed the following issues: 

type=AVC msg=audit(1211213302.497:1653): avc:  denied  { unlink } for  pid=27301 comm="spamass-milter" name="spamass-milter.pid" dev=dm-2 ino=254033 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1211282537.032:1800): avc:  denied  { write } for  pid=6975 comm="spamass-milter" name="spamass-milter.pid" dev=dm-2 ino=254033 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file

The first of these isn't a problem; the DAC permissions for the /var/run directory also prevent the dæmon (running as user sa-milt) from deleting the PID file. The problem is the second denial, where the dæmon (running in context spamd_t) is prevented from writing the PID to the PID file (which is initrc_var_run_t since it was created by the initscript). This represents a change in policy since Fedora 8, where spamd_t was allowed to do this write.

The solution was to change the context of the PID file to spamd_var_run_t so that the dæmon would be allowed to write to it. Hard coding the context type into the initscript is a no-no as it would make the initscript policy-specific. So the fix actually took two parts:

  1. Fixing policy to make the default context for /var/run/spamass-milter.pid one that is writeable by the spamass-milter dæmon (i.e. spamd_var_run_t in current policy). This was done in selinux-policy-3.3.1-55.fc9.

  2. Fixing the initscript to restore the default context for the PID file before starting the dæmon: 
  3. --- /etc/rc.d/init.d/spamass-milter.orig        2008-05-20 12:48:02.000000000 +0100
+++ /etc/rc.d/init.d/spamass-milter     2008-05-20 12:38:24.000000000 +0100
@@ -44,6 +44,7 @@
        echo -n $"Starting ${desc} (${prog}): "
        touch ${pidfile}
        chown sa-milt:sa-milt ${pidfile}
+       [ -x /sbin/restorecon ] && /sbin/restorecon ${pidfile}
        daemon --user sa-milt /usr/sbin/${prog}-wrapper -p ${SOCKET} -P ${pidfile} ${EXTRA_FLAGS}
        RETVAL=$?
        echo

  4. This fix was incorporated into spamass-milter-0.3.1-8.fc9

With that I was able to turn back off the dontaudit rules, go back into enforcing mode and successfully restart the service: 

# semodule -B
# setenforce 1
# service spamass-milter restart

Recent