Some time back I set up a new server machine running Fedora Core 4 x86_64, with Postfix as the MTA, and with the Mailman mailing list manager. I have a very slightly nonstandard Postfix setup, with recipient_delimiter set to a hyphen character (“-”) instead of the default plus character (“+”), in order to ease the transition from Qmail to Postfix. At first it seemed pretty easy to get this all working. But then it broke, for no apparent reason.
When I first noticed that the mailing lists had stopped working, it took me a while to track it down to a problem with SELinux security contexts. I’m running with the Fedora “targeted” policy. What I eventually discovered was that all of the files in /usr/lib/mailman had somehow gotten the wrong context. They must have had the right context at one time, since the lists worked for a while, and I’m not sure what might have changed them. The /sbin/restorecon program makes it easy to fix this sort of problem. After I did that, I sent out a test message, which I received back from the list, so I thought everything was copacetic.
Today I noticed that it wasn’t working right again. After a bit more time grovelling through log messages and such, I found several problems.
The security context for the postfix-to-mailman-2.1.py script, which I’d installed in /usr/lib/mailman/bin, was system_u:object_r:bin_t, but from the audit log it appears that the Postfix pipe transport program runs as system_u:system_r:postfix_pipe_t, and was failing to invoke the program. I tried to do a “chcon -r
system_r -t postfix_pipe_t postfix-to-mailman-2.1.py” as root, but it reports “permission denied”.
I eventually figured out that the chcon would succeed if I turned off enforcing, did the chcon, then turned it back on.
Unfortunately even after doing that, the Postfix pipe transport program is still not allowed to execute the script. I’m not sure what’s going on, so I’ll have to ask on the Fedora SELinux mailing list.
More surprising is that due to the different recipient_delimiter value, the script was failing for any of the mailing lists that have a hypen in their name, because the line in /etc/master.cf that defines the mailman transport was only passing in the {user} variable, which has anything that looks like a suffix stripped off. I changed the mailman transport line to also pass in {extension}, and changed the script to accept that and if non-null append it (with a hyphen) to the user.
Now it all seems to be working except that I have to run it with enforcing off until I find out how to set the right security context for the script.