[Mailman-Developers] Re: [Mailman-Users] Old Question, New Twist

[Barry A. Warsaw]

[Cc: changed to mailman-developers -BAW]

>>>>> "PC" == Paul Cox <paul@coxcentral.com> writes:

    PC> I'm that one that's done the last couple of Mandrake .rpm's
    PC> for Mandrake.  Let me help you out.

Maybe we should coordinate to make things easier (or more visible) for
RPMs.  I definitely don't have the time to support them, and am very
glad that you do, but maybe we can make things easier.

    >> My problem is the age old: Failure to exec script. WANTED gid
    >> 99, GOT gid 12. (Reconfigure to take 12?)  554 5.3.0 unknown
    >> mailer error 2

    PC> The reason for this is easy.  Since Mandrake installs the
    PC> Postfix MTA by default (you have to go out of your way to use
    PC> sendmail instead), that's how the .rpm configures Mailman
    PC> during the build.  Postfix delivers mail as gid nobody (99),
    PC> while sendmail delivers mail as gid 12 (mail).  Unfortnately,
    PC> you can't build an .rpm for both ways.  Since Postfix is the
    PC> default (and recommended) MTA, that's the one I went with.

I've been thinking in the background about how to make the compiled in
gid a run-time option.  I've always considered it difficult and unsafe
to do, but here's an idea:

What if the mail and cgi wrappers took an optional argument (say -g)
on the command line to specify the gid it looked for.  No -g and it
falls back to the compiled value.

We'd have to #ifdef this feature though, and the default would be to
disable it, because I believe it would allow untrusted users to defeat
this test fairly easily.  That might be too big a security hole.

On second thought, maybe we allow ifdef'ing out the gid check
altogether?

On third thought, we could try to put the gid out of a config file,
but it's such a pain to handle this in pure-C that I've avoided doing
it.  Maybe we need to bite the bullet?

The other issue here is that by keeping the wrappers as small as
possible, we can feel better about their security.  The more
complexity we introduce, the more exploits we potentially open up.

Thoughts?
-Barry