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:
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.
- Fixing the initscript to restore the default context for the PID file before starting the dæmon:
--- /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
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