[Mailman-Users] Re: [Mailman-Developers] Odd b5 behavior

[Ken Manheimer]

I've identified the reason for the problem corbett was having, and have
a workaround.

The problem appears to be another linux-specific item, having to do with
the apparent fact that effective gid's are not inherited by forked
processes. I'd be curious to get the scoop on this from any linux gurus
out there.

Corbett was seeing mail submissions completely disappearing - making it
to the maillist, but never showing up, without any logged error
messages.  The failure was happening when the new delivery mechanism was
attempting to place the messages on the outgoing queue.  The data
directory was writable by mailman, and the mail wrapper executable forks
and execs the maillist script with the mailman effective group id. 
However, the delivery mechanism runs in a subsequently forked process of
the maillist script - and apparently, forked processes (at least, forked
scripts) in linux do *not* inherit the effective group id - contrary to
the practice on other unices.  Linux folk, is this correct? 

The immediate workaround for those of you running mailman 1.0b5 under
linux is to fiddle with the ownership of the ~mailman/data directory a
bit: set the owner id to 'mail' (or whatever your mail process runs
with), make sure the group id is 'mailman', and make sure that it
enables user and group write. 

The real question, though, is whether there is any way in linux to
enable forked processes, even scripts, to inherit the effective gid of
the forking script.  Any obscure system call for that, or something,
which requires only membership in the group, not root privileges, to
run?

It might make sense for the installation mechanism to change the owner
of the data dir to that of the mail system, as the workaround does - but
that would sacrifice the ability to do that part of the installation
process as a regular user - root privilege is needed to chown.  So this
solution does not seem ideal.  There are other avenues, but we could
need to get the last word on the way that (redhat 5.x) linux is supposed
to be working, and what people normally to do achieve the kinds of 
things we're aiming for.  Insight and suggestions are welcome!

Ken Manheimer		  klm at python.org	    703 620-8990 x268
	    (orporation for National Research |nitiatives

	# If you appreciate Python, consider joining the PSA! #
		  # <http://www.python.org/psa/>. #