Bug 74165 - SPEC file fix for Postfix/Mailman GID
SPEC file fix for Postfix/Mailman GID
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mailman (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-17 03:12 EDT by Dax Kelson
Modified: 2014-01-21 17:48 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-24 15:40:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dax Kelson 2002-09-17 03:12:14 EDT
Description of Problem: 
 
Mailman won't run if if the incoming mail delivery isn't running as the GID 
specified at compile time. There are many ways to tie Postfix and Mailman 
together, in many of those scenarios, the incoming mail delivery runs as user 
and group mailman. 
 
Luckily we can compile in multiple GID values, so this is easy to fix. 
 
In the SPEC file, change: 
 
%define mailgroup  mail,nobody 
%define mailgid	   12,99 
 
to 
 
%define mailgroup  mail,nobody,mailman 
%define mailgid    12,99,41 
 
I've tested this and it solves the problem. 
 
Version-Release number of selected component (if applicable): 
mailman-2.0.13-1
Comment 1 Dax Kelson 2002-09-18 02:05:26 EDT
This also applies to Limbo/Null, etc.
Comment 2 Dax Kelson 2002-12-01 18:41:41 EST
This applies to Red Hat Linux 8.0 as well. This seems like an easy bug to fix. :)
Comment 3 Dax Kelson 2003-01-07 23:51:19 EST
Any comment on this? This enables better integration of mailman and Postfix.
Comment 4 John Dennis 2003-01-08 09:13:30 EST
I have just picked up ownership of the mailman and postfix RPM's here at RedHat.
So I'm just coming up to speed on their issues. I am in the process of upgrading
the mailman RPM to the new 2.1 release and going through the spec file. The
package build has already brought issues to light with user id's so I will
definately be looking at this. Please be patient, I do have a goal to get new
versions of these packages out for 8.1. With luck I hope to have a new mailman
package pushed out to Rawhide by tomorrow and will look for help verifying the
robustness of the package from those who are experts in using it.
Comment 5 Warren Togami 2003-01-09 02:07:40 EST
Will any changes be needed to my exisitng mailman data/configs in order to test
Mailman 2.1?  I am currently using mailman-2.0.13-1.
Comment 6 John Dennis 2003-01-09 13:48:55 EST
Dax wrote that "Luckily we can compile in multiple GID values, so this is easy
to fix."

Unfortunately that is not true, only one gid is every compiled in. One can
specify multiple gid's to the configure script, but the configure script treats
this as an ordered list, it steps through the list testing each gid in the list
until it finds a valid one. This gid is then passed as the MAIL_GROUP macro when
compiling src/mail-wrapper.c.

This creates a problem for producing a binary RPM because the id's that will be
selected from the list are those on the build machine that produced the binary
RPM, not the target machine the RPM will be installed on. If the gid is not
appropriate for the target machine the user could get the SRPM and do a build
and then install the resulting RPM, that should fix the problem for the user.
Thus I'm happy to add the extra gid to the spec file, but its less than the
solution I think you're looking for because it won't work for binary RPM's which
is what the majority of user's install.

Also, its important to note the syntax for specifying multiple id's is with
whitespace separation between the ids (or symbolic names), NOT with commas, I
have no idea how the previous spec file worked. In both the previous release and
the new 2.1 release the list is passed to the python split() string function.
Without any arguments to split() the separation tokens default to whitespace.
 
Comment 7 Dax Kelson 2003-01-09 14:01:00 EST
"...but the configure script treats this as an ordered list, it steps through 
the list testing each gid in the list until it finds a valid one. This gid is 
then passed as the MAIL_GROUP macro whencompiling src/mail-wrapper.c"

Additional --  not understood things are happening then since when doing:
%define mailgid  12,99,41
It works. And the wrapper is OK with being invoked as GID 41.

By your description above only '12' should be getting compiled in as GID 12 
exists on all Red Hat machines and is first in the list.
Comment 8 John Dennis 2003-01-09 14:29:22 EST
O.K., I see what is going on now. The pristine upstream mailman sources only
allow a single gid. But there was a patch on the old 2.0.9 release that allowed
for multiple gid's. I had been working on the assumption the patches from 2.0.9
had been submitted and accepted by the upstream maintainers and I didn't need to
bring old patches forward into the current release. This does look like a
worthwhile patch to pull forward.
Comment 9 Dax Kelson 2003-01-09 14:36:08 EST
Someone should see if the Mailman developers will accept that patch.
Comment 10 John Dennis 2003-04-24 15:40:50 EDT
this was fixed long ago, the bug should have been closed out. Patches were sent
upstream.

Note You need to log in before you can comment on or make changes to this bug.