#acl PaulHowarth:read,write,admin,revert,delete All:read

=== Tuesday 20th May 2008 ===

==== Fedora Project ====

According to [[RedHatBugzilla:447247|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`.
 1. 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
}}}

----