diff options
Diffstat (limited to 'contrib/README.redhat_fhs.patch')
| -rw-r--r-- | contrib/README.redhat_fhs.patch | 305 |
1 files changed, 305 insertions, 0 deletions
diff --git a/contrib/README.redhat_fhs.patch b/contrib/README.redhat_fhs.patch new file mode 100644 index 00000000..a36d33ef --- /dev/null +++ b/contrib/README.redhat_fhs.patch @@ -0,0 +1,305 @@ +The following is the contents of the post at +<http://mail.python.org/pipermail/mailman-developers/2004-October/017343.html>. + +The actual patch is at redhat_fhs.patch in this (contrib/) directory. + +Note that this patch only patches configure.in, so if you apply this patch, +you need to then run GNU autoconf to build the patched ./configure. + + +[Mailman-Developers] FHS installation changes +John Dennis jdennis at redhat.com +Mon Oct 18 22:26:21 CEST 2004 + +Overview: +--------- + +Earlier I wrote about our (Red Hat's) desire to make mailman be FHS +compliant, in part to allow mailman to fall under the protection of +SELinux security policy which is file and directory based and as a +consequence much easier to author when packages install into canonical +locations (e.g. FHS). + +Previously we had installed all of mailman under /var/mailman +(prefix=var_prefix=/var/mailman) and I had proposed a much simpler +change of just setting prefix=/usr/lib/mailman. This took care of the +majority of SELinux issues and limited the scope of changes. There was +a concern that sites and administrators who were familiar either with +our RPM, the upstream package, or were working with an existing +installation would run afoul of the location changes and keeping them +to absolute minimum was advantageous. However a few folks in private +email pointed out that if changes were going to occur its best to do +it all at once and not piecemeal, in other words endure the pain once. + +Thus I embarked on an exercise to make everything FHS compliant. There +are two reasons I'm addressing the developer community here: + +1) I want to apprise you of the exact changes, their rational, provide + a patch against 2.1.5 and solicit review. + +2) Test the results. + +Description: +------------ + +Currently the configuration allows for partitioning the mailman +installation between two installation roots, prefix for non-modifiable +files and var_prefix for variable data. This is a great start and +covers 90% of the installation, but there remains a small set of items +which even in this scheme are not FHS compliant, in summary: + +1) config files located under /etc + +2) pid file located under /var/run + +3) queue files located under /var/spool + +4) lock files located /var/lock + +5) log files located under /var/log + +I think one could characterize the competing installation philosophies +as follows: + +Mailman not knowing what type of system its going to be installed on +elects to group all of its files together (makes perfect sense). FHS +on the other hand says most packages share common traits and we group +by functional component thus spreading out package installations +across a diverse set of directories. + +Implementation: +--------------- + +I discovered I had to add some new directories to configure and alter +some of the *_DIR variables in Defaults.py.in so they pick up their +values from configure. My strategy was to allow configure when run +without providing any other parameters to produce the exact same set +of installation defaults as previously existed so unless you specify a +different installation mapping a user won't see any change. + +Configure added: + +--with_lock_dir +--with_log_dir +--with_config_dir +--with_data_dir +--with_pid_dir +--with_queue_dir + +I also modified bin/check_perms so it was aware of the new directory +specifications. The patch also made a few non FHS fixes to the install +target of the Makefiles, some generic issues were discovered when +testing check_perms. Those changes included: setting SETGID on the root +prefix and var_prefix directories, check_perms demands all +directories, including the roots are SETGID. The messages Makefile was +creating a two level directory hierarchy but only setting SETGID on +the child. Some of the "make install" logic seemed to depend on the +property that new child directories created under a parent that was +SETGID inherits the SETGID property. To the best of my understanding +this is true only on Linux and Solaris and not generally portable. I +replaced the use of the local mkinstalldirs (and subsequent chmod g+s) +with what I believe is much more standard "install -d" and with the +SETGID as part of the mode. All directories are created this way, +nothing depends on inheritance. I also removed some ancient Makefile +cruft that is no longer in use, variables no longer initialized by +configure, etc. (just confusing, accidents waiting to happen if +someone thought it was valid). + +Issues: +------- + +Most of the changes were isolated to whole directories and were well +defined. Only the contents of DATA_DIR required splitting its contents +across more than one directory. DATA_DIR contained both pickle files +created during processing and what would be characterized as +configuration files (e.g. password files, MTA alias +files. sitelist.cfg). A new directory CONFIG_DIR was created (in FHS +its /etc/mailman) to hold what has traditionally been in /etc +(e.g. configuration, passwords, aliases, etc). The other things that +were in DATA_DIR was left there. + +The mailman configuration file presented the biggest challenge and the +one exception to FHS. The culprit is mm_cfg.py. This is really +mailman's configuration file and it should be located in CONFIG_DIR +(/etc/mailman). But there were several major problems with moving that +file there. + +1) It's executable python code, not a text file containing + configuration parameters. Executable code should be in a "lib" or + "bin" location. Why is this an issue? Because SELinux pays very + close attention to who can execute and with precise control over a + host of run time operations, its often based on directory + location. But most importantly config files have to be editable, + security properties transit when modified and new files pick up + security properties of the directory that contains the file. We do + not want any file created (or modified) in a configuration + directory to pick up security permissions granting execution + rights or for that matter any other run time security permissions. + +2) The import of mm_cfg and its directory (Mailman) is all through the + code, it would be very invasive to change. If mm_cfg continues to be + executable python code as opposed to a text file then paths.py + would have to be altered to prepend /etc/mailman to the import + path, another significant security violation. + +3) Any experienced mailman admin will know that mm_cfg.py is located + with the rest of the mailman executable code under $prefix/Mailman + and will expect to find this critical file there. + +I concluded for the above reasons that mm_cfg.py in the 2.1.x +time frame was best handled as an FHS exception. Our rpm does however +create a symbolic link from /etc/mailman/mm_cfg.py to +$prefix/Mailman/mm_cfg.py so that it "appears" in configuration +directory. This will prepare admins to start looking for mm_cfg along +with the other configuration files. Note that security policies do not +transit across links therefore there are no security policy issues +with the sym link in /etc/mailman. Hopefully in MM 3.0 the +configuration file will be textural which will eliminate the security +policy issue. Also note that sitelist.cfg was completely moved to +/etc/mailman as that is not executed, but rather "evaluated" (I think +evaluation in /etc is fine, but I'm not 100% positive :-). + +Request for testing: +-------------------- + +I have created RPM's with the changes outlined above and documented +below, you may obtain them here: + +ftp://people.redhat.com/jdennis/mailman-2.1.5-26.i386.rpm +ftp://people.redhat.com/jdennis/mailman-2.1.5-26.src.rpm + +I have tested the new rpm and have not found any problems. The +modified check_perms does not report any problems. But I'm well aware +my testing is limited and my comprehension of mailman is limited, it +is inevitable something has been missed that only wider testing will +reveal and I would appreciate that testing by experts. These changes +are slated to appear in our Fedora Core 3 release which is closing in +a couple of days in preparation for release. Testing prior to that +close would be appreciated. Note that with Fedora Core 3 SELinux will +be enabled by default in "targeted mode". This means that SELinux +policy will be applied to key system services only, mail and hence +mailman is one of those key system services. Ideally any testing +should be done from "rawhide" with the 2.1.5-26 version of mailman and +the new matching SELinux security policy, but I would be perfectly +happy for any testing of the basic rpm even if its not running under +targeted security policy. + +Patch File: +----------- + +Attached is the patch made against a virgin 2.1.5 tarball with the +changes outlined above. + + +User / Admin Documentation: +--------------------------- + +The following is what I prepared for our installation documentation +which can be found in /usr/share/doc/mailman-* + + + +IMPORTANT NOTE FOR USERS UPGRADING FROM A PREVIOUS RED HAT MAILMAN +INSTALLATION OR THOSE FAMILIAR WITH "STANDARD MAILMAN INSTALLATIONS" + + Earlier Red Hat mailman rpms installed all of the mailman files under + /var/mailman. This did not conform to the Filesystem Hierarchy + Standard (FHS) and created security violations when SELinux is + enabled. As of mailman-2.1.5-21 the following directory and file + changes occurred: + + variable data (e.g. lists) is in /var/lib/mailman, library code, + executables, and scripts are located in /usr/lib/mailman, lock files are in + /var/lock/mailman, the pid file is in /var/run/mailman, qfiles are in /var/spool/mailman, + and configuration files have been moved to the new /etc/mailman + + If you previously had mailman installed and have edited files in + /var/mailman (e.g. configuration) you will need to move those changes + to their new locations. + + The mapping of old locations to new locations is as follows: + + Directory Mapping: + /var/mailman --> /var/lib/mailman + /var/mailman/Mailman --> /usr/lib/mailman/Mailman + /var/mailman/archives --> /var/lib/mailman/archives + /var/mailman/bin --> /usr/lib/mailman/bin + /var/mailman/cgi-bin --> /usr/lib/mailman/cgi-bin + /var/mailman/cron --> /usr/lib/mailman/cron + /var/mailman/data --> /var/lib/mailman/data + /var/mailman/lists --> /var/lib/mailman/lists + /var/mailman/locks --> /var/lock/mailman + /var/mailman/logs --> /var/log/mailman + /var/mailman/mail --> /usr/lib/mailman/mail + /var/mailman/messages --> /usr/lib/mailman/messages + /var/mailman/pythonlib --> /usr/lib/mailman/pythonlib + /var/mailman/qfiles --> /var/spool/mailman + /var/spool/mailman/qfiles --> /var/spool/mailman + /var/mailman/scripts --> /usr/lib/mailman/scripts + /var/mailman/spam --> /var/lib/mailman/spam + /var/mailman/templates --> /usr/lib/mailman/templates + /var/mailman/tests --> /usr/lib/mailman/tests + + File Mapping: + /var/mailman/data/adm.pw --> /etc/mailman/adm.pw + /var/mailman/data/creator.pw --> /etc/mailman/creator.pw + /var/mailman/data/aliases --> /etc/mailman/aliases + /var/mailman/data/virtual-mailman --> /etc/mailman/virtual-mailman + /var/mailman/data/sitelist.cfg --> /etc/mailman/sitelist.cfg + /var/mailman/data/master-qrunner.pid --> /var/run/mailman/master-qrunner.pid + + Discussion of directory and file relocation: + + Two new directories were created and three existing directories which + were hardcoded are now configurable. + + PID_DIR is used to hold the process id and is new because FHS wants + pid files to be located in /var/run. The FHS says when there is only a + single pid file it should be located in /var/run/<name>.pid, and when + there are multiple pid's files they should be located together in a + subdirectory, /var/run/<name>/. Currently mailman only has a single + pid file, but it does have multiple processes (qrunners). Also SELinux + security policy is easier to write if processes are segregated into + individual subdirectories. Therefore we elected to place the mailman + pid file in its own subdirectory, there is some debate if this is 100% + FHS compliant because there is only currently a single pid file, but + this gives us greater future flexibility and is in the spirit of FHS. + + CONFIG_DIR is used to hold the site configuration files. FHS wants + configuration files stored in /etc/mailman. Previously configuration + files were mixed in with data files in DATA_DIR and with the run-time + code (e.g. Mailman/mm_cfg.py). CONFIG_DIR continues to exist but is + now restricted to data files (e.g. python pickle files). The password + files, alias files, and .cfg (e.g. sitelist.cfg) files have been moved + to CONFIG_DIR. mm_cfg.py which is the primary mailman configuration + file was presented a bit of a dilemma. In theory it should be located + in /etc/mailman, however it is executable code which argues it should + be located with the other executable files, it has traditionally lived + in $PREFIX/Mailman and experienced mailman admins will expect to find + it there. Modifying all the mm_cfg import statements and paths.py was + believed to be too invasive a change, and technically its part of the + "Mailman" package and moving it would take it out of the package + (although currently I don't think that presents any known + issues). Instead a compromise approach was adopted, mm_cfg.py is + symbolically linked into the /etc/mailman directory pointing to + $PREFIX/Mailman/mm_cfg.py. Thus mm_cfg.py "appears" in the + configuration directory but retains its traditional location, this was + deemed a reasonable compromise for the mailman 2.1.x timeframe. + + sitelist.cfg has a symbolic link in its old location in the DATA_DIR + pointing to its new location in the CONFIG_DIR. + + New Directories (can be specified as parameter to configure): + + CONFIG_DIR: default=$VAR_PREFIX/data FHS=/etc/mailman + PID_DIR default=$VAR_PREFIX/data FHS=/var/run/mailman + + Existing directories that can now be specified as parameter to configure: + + LOCK_DIR: default=$VAR_PREFIX/locks FHS=/var/lock/mailman + LOG_DIR: default=$VAR_PREFIX/logs FHS=/var/log/mailman + QUEUE_DIR default=$VAR_PREFIX/qfiles FHS=/var/spool/mailman + + +-- +John Dennis <jdennis at redhat.com> |