[Mailman-Developers] Q: Security checking in wrappers and config file

Michael Tokarev mjt@tls.msk.ru
Sat, 20 May 2000 13:19:23 +0400


Hello!

I looked to mailman wrappers code, and found that it performs
some strange to me fings.  First of all, it is seemed to be not
good idea to define uids/gids as numbers inside executable
wrappers (for mail and www).  I think that something caused
the current approach when the code was developed, but don't
know what it was...

Why not use the following schema:

* made one config file in well-known place (e.g. /etc/mailman.conf)
  and require that it writable only by root (maybe)
* place all the info there (including mail gid, www gid,
  location of mailman "home" directory etc. (the last one
  will be PYTHON_PATH; also, it can be read using getpwnam)
* do not rely on setgid for mailman home, but instead use real
  setgid calls

With current layout, it is not possible to split programs
and data.  I want to put all executables into, say, /usr/mailman,
and all data to /var/[spool/]mailman and /var/log/mailman
(and mount /usr read-only).  Having config file it is simple.

Also, with current approach, many files will be owned by some
strange users when mailman operates.  For example, config.db
file owned by nobody (run from www) or whatether owner when
run from MTA, the same cab be with logs.  This is potentially
unsecure, as, e.g., any other cgi script can read _and_ write
this config file as a result, not only mailman group.
Yes, rewriting is not very good (not an atomic operation),
but I prefer security here...

And some more thoughts.
Many MTAs sets environment variables when delivering to programs.
For example, postfix sets LOGNAME to recipient name, DOMAIN to
part of recipient address after @, FROM to envelope address
and so on, and those variables are _safer_ to use (in case of
postfix) than information from mail contents (with both sides --
MTA can have more info available about real person who sends this
mail, based on, say, smtp AUTH commands, and, in case of postfix,
those values are already parsed by intelligent mechanism and with
all strange/funny/control characters removed).
Is it possible candidate to enhancement to include usage of those
variables?

Comments?

Regards,
  Michael

P.S. I'm new to this list... :)