[Mailman-Users] "No such list mailman" after creating list

[John Dennis]

On Tue, 2005-07-26 at 08:05 -0700, Mark Sapiro wrote:
> This has to be a case of the web server not being able to access the
> lists/ directory or its subordinates. If bin/check_perms finds no
> problems, maybe its a SELinux issue.

[ Note: I will create a new mailman FAQ entry for SELinux, since this
issue keeps coming up. ]

If it is an SELinux issue here are a set of things you can try:

1) Put SELinux into "permissive" mode, this logs avc errors but permits
the operation that would otherwise have been denied. The idea here is to
log where SELinux would prohibit an access but not to cause a failure,
then if it is SELinux causing the problem you can go back later and fix
it. To put SELinux into permissive mode you must be root AND in the
sysadm_r (or equivalent) role.

# getenforce
Enforcing
# setenforce Permissive
# getenforce
Permissive

2) Retry the operation. Does it work now? If not, it wasn't SELinux, go
look elsewhere. If it now works then it was SELinux preventing the
operation. Now find out why. You'll need to look for "avc:  denied"
messages. These are typically logged to either the system log file or if
the audit daemon is installed to the audit log, on Fedora systems this
would be:

/var/log/messages
/var/log/audit/audit.log

Grep these files for avc:

grep avc: /var/log/messages /var/log/audit/audit.log

Look for "denied" messages whose "comm" or "name" fields are mailman
related. Contact your vendor to get the problem resolved, this typically
means installing a new security policy with the fix. Installing the
newest security policy probably a good initial step. On Fedora this can
be done this way:

# yum update selinux-policy-targeted

You can also run with SELinux disabled, but these days running with open
servers without the high level of security protection offered by SELinux
is risky. If you have SELinux available you should try to make sure it's
enabled to protect yourself.

Note: Vendors who are shipping SELinux have crafted security policies to
match their distributions, e.g. where things are installed on their
distribution. If you build and install mailman yourself you are side
stepping all the policy work done by the vendor. You'll either have to
craft your own policy to match and properly label all system objects
(files, sockets, etc.), disable SELinux, or use the vendors mailman
package (by the way this applies to everything under SELinux control
which for a mailman installation includes your MTA and web server. Your
vendor has worked hard to make sure the security policy works for all
components, if you build and install anything yourself you may in
conflict with how your vendor has crafted the security policy).

-- 
John Dennis <jdennis at redhat.com>