Hi,
there is something really nasty about the way postfix chooses its UID/GID (recall: it's based on the UID of the alias file where the alias has been taken from).
So if you have a somewhat complex configuration, you can have postfix invoke the mailman command from two different aliases files (/etc/aliases and /var/local/mailman/data/aliases), which don't necessarily have the same UID.
And then you're toast by Mailman gid check.
I would like to know if this check can be expanded to list all GID that mailman will accept? Or if I should just be more carful in setting up my system? :)
The question is really a FAQ, but the answer is not fully satisfying.
README.POSTFIX says:
- When you configure Mailman, use the --with-mail-gid=mailman
switch (actually, this will be the default if you configured
Mailman after adding the `mailman' owner). Because the owner of
the aliases.db file is `mailman', Postfix will execute Mailman's
wrapper program as uid and gid mailman.
I'd like to have either the possibility of configuring: --with-mail-gid=mailman,nogroup
or an update in the README.POSTFIX file saying, more explicitly, that all mailman calls from postfix should be done through aliases files that all belong to the same user (mailman) that has the mailman GID... but I'm not sure of the wording that should be used - so weird is this.
-- Fil
On Sat, 2004-10-16 at 04:30, Fil wrote:
I would like to know if this check can be expanded to list all GID that mailman will accept? Or if I should just be more carful in setting up my system? :)
We patch mailman to accept multiple GID's. The patch is attached. It includes changes to configure to accept a list of GID's so don't forget if you apply the patch you'll have to run autoconf to generate a new configure.
BTW, the preferred solution as you allude to is to be rigorous with the identity and permissions of system components. This patch is more of a concession to the dilemma of distributing mailman in an environment where other packages and configurations may be installed which are beyond our control than a suggested approach. Ideally this would not be necessary and for what its worth I have some misgivings about it. Our distribution is moving to a more constrained set of packages and much more security driven. This patch which has been in our RPM for a while is on the table for removal because of these security concerns.
John Dennis <jdennis@redhat.com>
participants (2)
-
Fil
-
John Dennis