Bug 135073 - /usr/lib/mailman/Mailman/mm_cfy.py needs to be written, move to /var
/usr/lib/mailman/Mailman/mm_cfy.py needs to be written, move to /var
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mailman (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-08 10:05 EDT by Tom London
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-10 06:57:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom London 2004-10-08 10:05:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002
Firefox/0.10.1

Description of problem:
To configure mailman, you need to enter hostnames into
mm_cfg.py which now lives in /usr/lib/mailman/Mailman/

In addition, /usr/lib/mailman/bin/check_perms reports
errors in permissions for a couple of files, including
/usr/lib/mailman/bin (wants it to be 02775).

Shouldn't files that need modification should be in /var?

Version-Release number of selected component (if applicable):
mailman-2.1.5-21

How reproducible:
Always

Steps to Reproduce:
1. install mailman
2. need to modify mm_cfg.py
3. run /usr/lib/mailman/bin/check_perms
    

Additional info:
Comment 1 Tom London 2004-10-08 10:20:56 EDT
Sorry, other file reported by check_perms:
/usr/lib/mailman/cron/crontab.in bad group (has: root, expected mailman)
Comment 2 John Dennis 2004-10-08 13:26:01 EDT
Thank you for the bug report. These are all problems/issues that are
being worked on as we speak. Other directories and files have since
been moved for better FHS compliance. 

You raise a good point about mm_cfg.py. It's really not clear to me
where this should live because its both an config file AND executable
code (an unfortunate implementation choice). In theory it should be in
/etc/mailman as a config file, but /etc shouldn't have any executable
code in it, nor should it be in /var because /var shouldn't have any
executable code either. The executable code of mailman should be in
/usr/lib/mailman, and in fact the imports that Mailman uses to find
mm_cfg expect to find it there with all the other mailman code, yet
its a user writable config file! 

I'm undecided at the moment how to deal with this. Initial thinking on
my part is this is an unfortuante exception we're just going to have
to live with and hope MM 3.0 does a better job of partitioning the
file set.
Comment 3 John Dennis 2004-10-08 13:27:53 EDT
BTW, I'm almost done with a new mailman rpm that attempts to be fully
FHS compliant (with the eception of mm_cfg), no errors are reported by
check_perms with this version. Would you be interesting in beta
testing it?
Comment 4 Tom London 2004-10-08 15:00:46 EDT
yup!

Let me know when/where :)

tom
Comment 5 Russell Coker 2004-10-09 02:06:33 EDT
Lots of config files in /etc are executable shell scripts.  There 
are /etc/rc.d/init.d files and config files that set environment 
variables such as /etc/selinux/config . 
 
/etc seems a good place for this. 
Comment 6 Axel Thimm 2004-12-20 07:30:12 EST
I'm seconding the idea of moving it under /etc/mailman and have
/usr/lib/mailman/Mailman/mm_cfg.py simlink to it (the reverse
situation than now on FC3).

It also isn't an executable file, it has neither the required
permissions, nor any magics in the first line. It is just imported as
a module and you can certainly inject code into mailman that way, but
so are all config files under /etc/sysconfig, you could embed nasty sh
code there, too :)
Comment 7 Harald Hoyer 2005-11-10 06:57:46 EST
/etc/mailman/mm_cfg.py

Note You need to log in before you can comment on or make changes to this bug.