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

[Barry A. Warsaw]

>>>>> "MT" == Michael Tokarev <mjt@tls.msk.ru> writes:

    MT> Another one cause are the numerous distribution systems like
    MT> rpm, deb etc that cames in binary form, thus compiled on other
    MT> system.  People still sometimes prefer this.  And there is no
    MT> guarantee, for example, so that rpm/deb will install mailman's
    MT> owner using the same uid/gid (f.e. if that ids already used on
    MT> target machine).

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

It's probably worth looking into -- after the 2.0 release.

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

I personally hate adding things to /etc, but maybe that's my old Unix
bias showing through.  RPMs and the like do change the picture.
paths.py serves a useful purpose though, very Python specific, and it
makes no sense to either add general external configuration parameters
to it or change the way paths.py interacts with the rest of Mailman.
Besides, paths.py is a text file, so it's easily edited if Mailman is
relocated.

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

This was all very difficult to get right, and seemed fragile,
especially when you're coming into the system through multiple paths:
mail program, cgi-bin, command line, cron.  The current approach
"works" and my motto's been IIABDFI (if it ain't broke, don't fix it).

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

Overwriting config.db is scary because if there's an unforseen error,
you corrupt your database.  Bad news!

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

It's an interesting idea, well worth looking into.  Thanks for adding
to the discussion.

-Barry