[Mailman-Developers] Q: Security checking in wrappers and config
Barry A. Warsaw
Wed, 31 May 2000 00:49:51 -0400 (EDT)
>>>>> "MT" == Michael Tokarev <firstname.lastname@example.org> 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
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.