Ok, thanks, Harald, for your interest.

Harald Meland wrote:

[Michael Tokarev]

...

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).

These values are derived from whatever GIDs the configure script finds. You can specify what group name to use with the "--with-mail-gid" and "--with-cgi-gid" configure options.

This is ok when you installed on the same system that the thing was built on. And moreother, that system shoud have that accounts defined. I, for example, prefer to build on one machine and install on another -- I have inet-access server and build machine, the first one lacks complier etc (compiler should not exists on router f.e., atleast for some strange security issues... :). Another one cause are the numerous distribution systems like rpm, deb etc that cames in binary form, thus compiled on other system. People still sometimes prefer this. And there is no guarantee, for example, so that rpm/deb will install mailman's owner using the same uid/gid (f.e. if that ids already used on target machine). Also, if I reinstall (or have) another mailer, I will need it's own tweaking or mailman's one (this is what I have already -- postfix executes all programs defined in aliases files owned by root as nobody; I tweaked postfix's config and added mailman's aliases file that is owned by mail(!), as mailman expects to be called with gid=mail).

Ok, it is not so important to make uid/gid configurable; but -- just why to not add one extra call -- getXXXent -- to leave this in symbolic form? This is trivial, no need to determine gid on compile time, and all incompats with different uid/gid for the same name will go away. Is it considered security harmless?! -- this question I asked already.

...

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)

Why? What does this win us over the situation we have now?

There is paths.py file in each subdir. Why just not to move it to /etc?

The only "advantage" I can see is that you wouldn't have to recompile Mailman if some of the GIDs Mailman is invoked from change; editing the config file will suffice. However, is that really a common enough occurence that we'd want to require a separate config file for it?

My suggestion (but that I not mention there) is to place all paths into this file (e.g. logdir=xxx, listsdir=xxx etc). uid/gid is not so useful there as those things, but this will have small advantage (if I change mailer etc).

...

• do not rely on setgid for mailman home, but instead use real setgid calls

Ummm, I don't think I understand what you mean...

Oh, I'm stupid... :) I mean here: mailman's _directories_ uses g+s mode. So, all files created there will have gid=mailman (e.g.) automatically. This seemed to be just to easy installation. All programs should be running with gid=mailman anyway -- why need g+s on dir!?

...

With current layout, it is not possible to split programs and data.

Not quite true; you can fake a split by substituting symlinks for the subdirs under $(prefix).

Yeah, it's true. A bit ugly but true, and I already attempted to do so.

...

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...

Ummm, I still don't follow you -- are you saying that we should use setuid instead of setgid stuff?

No. I just suggest to have real file's owner (pre-created file, not created anew). If we have created all required files at install time, we can preserve owners, but this requires owerriting them, not creating+renaming.

As for other cgi scripts being able to write lists' config.db files: Unless your web server user is a member of the mailman group, non-mailman-setgid cgi scripts may be stopped from accessing Mailman-internal data by

chgrp mailman $(prefix)/lists chmod o-rwx $(prefix)/lists

etc. (I think -- this is untested).

That is strange that this issue was not popped up before... This is the first that I found strange (after numeric gids inside wrappers) -- config is owned by nobody and by default accessable from www. And this is what I did right after -- chmod'ed o-wrx *, o+x cgi-bin etc. Untested -- just strange that noone looked to this before.

...

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?

Only if it would be a) safe and b) not too MTA-specific. In the example you provide, I don't think those two criteria are satisfied -- I'd either have to _explicitly_ tell Mailman that the MTA delivering to it is Postfix, or risk using heuristics to determine what MTA is doing the delivery. I suppose heuristics might easily be fooled if I pass similar environment variables on to e.g. an Exim daemon.

This can be done using custom classes for different MTAs. I don't know how hard it is to implement. You are definitely right here, too -- it is not a common scheme. Some mailers are safe in that aspects. I just curious a bit, and paranoid in security. All from info inside messages can be easily fooled as well, so, e.g., approve can be fooled etc. But if mta have, say, tls/sasl/etc extensions, this can be used safely. Not only based on env. vars, but on custom headers added by that mta (say, X-SASL-User: xxx).

...

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

Welcome!

Thanks. ;)

      Hopefully me being rather sceptic to the changes you are

proposing aren't ruining the first impression ;)

?? Sorry didn't understand you here... :) Oh my bad English!.. Mailman seemed to me at least slightly different than many other software that I seen before. Some of it's principles, namely, numeric ids and a mix of programs (read-only) and variable data, and also with some file permissions. Just wanted to see it good. And maybe my own The Right Thing (tm) is a bit different from yours ;)

-- Harald

Thanks. Regards, Michael.