Re: [Mailman-Users] Group mismatch error
Mark Sapiro replied to my posting about group-id mismatches, in part:
My questions are these:
1) Where is this group test being made?
In the wrapper /usr/lib/mailman/mail/mailman.
...
In a 'package' installation, the expected group is determined by what ever magic the packager has resorted to to avoid having to recompile the wrapper.
I was looking at this wrapper executable and how it is compiled. I needed to determine the "magic" involved. I have the "script" output of my installations on Solaris and Ubuntu. I found this Debian/Ubuntu patch 10_wrapper_uid.dpatch that contains, in part, this change to mail-wrapper.c: ===================================================================== --- mailman-2.1.4.orig/src/mail-wrapper.c +++ mailman-2.1.4/src/mail-wrapper.c @@ -74,7 +74,7 @@ fatal(logident, MAIL_ILLEGAL_COMMAND, "Illegal command: %s", argv[1]); - check_caller(logident, parentgroup); + if (getgid() >= 100 && getgid() != 65534) check_caller(logident, LEGAL_PARENT_GROUP); /* If we got here, everything must be OK */ status = run_script(argv[1], argc, argv, env); ===================================================================== The patch contains a similar patch to cgi-wrapper.c .
From the debian/changelog, with the oldest patch first:
------------------------------------------- mailman (1.0b7-1) unstable; urgency=low * Don't check caller gid in mail-wrapper -- Gergely Madarasz <gorgo@caesar.elte.hu> Fri, 8 Jan 1999 02:24:00 +0100 ------------------------------------------- mailman (2.0.3-2) unstable; urgency=low * Applied some old patches which had got lost, including allowing the calling of the wrapper scripts if GID == nobody or < 100. (Closes: #36010, #89564, #89848, 89818) -- Tollef Fog Heen <tfheen@debian.org> Wed, 14 Mar 2001 13:40:16 +0100 -------------------------------------------
From the Debian web site:
mailman (2.0.3-3) unstable; urgency=low * Mailman has supported having nobody as the CGI user for some time (closes: #36010) - Tollef Fog Heen <tfheen@debian.org> Fri, 16 Mar 2001 11:06:44 +0100 ------------------------------------------- There was no additional information on patches #89564, #89848, 89818. The patch appears to be calling check_caller only if the group is over 99 and not 65534, and it is calling that routine with a different parent group. But the mail-wrapper.c code has #define LEGAL_PARENT_GROUP MAIL_GROUP const char* parentgroup = LEGAL_PARENT_GROUP; I have no idea for the reasoning behind "Don't check caller gid in mail-wrapper", nor do I understand the reasoning for the "nobody" and "< 100" GID checks. I do not know if the change to the second parameter of check_caller is significant. When I built my 2.1.9 package, I did not include any of the Debian patches except for one that changes two parameters in Defaults.py.in: IMAGE_LOGOS DEFAULT_URL_PATTERN What I have on my Ubuntu test system in /etc/group is: daemon:x:1: list:x:38: I have to conclude that the straight Ubuntu/Debian package installation was not checking the group-id because the daemon and list groups have ID below 100. When I built and installed the 2.1.9 Ubuntu package without this patch, the Mailman code began checking the group-id and found a mismatch. I would appreciate it if someone would confirm my conclusions. Thanks. ---------------------------------------------------------------------- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone: +1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: BSFinkel@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994
Barry Finkel wrote:
The patch appears to be calling
check_calleronly if the group is over 99 and not 65534, and it is calling that routine with a different parent group. But the mail-wrapper.c code has
#define LEGAL_PARENT_GROUP MAIL_GROUP const char* parentgroup = LEGAL_PARENT_GROUP;
It's not really different. MAIL_GROUP is defined in the 'cc' command generated by configure with value equal to the --with-mail-gid argument or default. Then the first line above defines LEGAL_PARENT_GROUP with the value of MAIL_GROUP. the second line defines parentgroup as a constant character pointer (or string) equal to LEGAL_PARENT_GROUP. Whether check_caller is called with a second argument of parentgroup or LEGAL_PARENT_GROUP, the result is going to be the same although the latter may produce a compiler warning.
I have no idea for the reasoning behind "Don't check caller gid in mail-wrapper", nor do I understand the reasoning for the "nobody" and "< 100" GID checks. I do not know if the change to the second parameter of check_caller is significant.
If you didn't read <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.016.htp> which I referenced previously, read it now.
In brief summary, the MTA invokes Mailman's wrapper which is SETGID and Mailman's group ('list' in your case IIRC). Thus, the wrapper and the scripts it calls run as group 'list' so they have the permissions they need.
In order to prevent anyone who might have shell access to the server from running the wrappers as commands and doing whatever they might do, the wrapper is written to expect to be invoked by a specific group the group that the web server runs CGIs as in the case of the CGI
- the group that the MTA runs it as in the case of the mail wrapper,
wrappers. If it is not invoked by the expected group, it refuses to run (it dies in check_caller).
The Debian/Ubuntu patch allows any group with GID <100 in addition to the precompiled 'expected' group, presumably on the theory that untrusted users all have GIDs >=100 so letting any GID <100 run the wrapper is OK.
When I built my 2.1.9 package, I did not include any of the Debian patches except for one that changes two parameters in Defaults.py.in:
IMAGE_LOGOS DEFAULT_URL_PATTERNWhat I have on my Ubuntu test system in /etc/group is:
daemon:x:1: list:x:38:I have to conclude that the straight Ubuntu/Debian package installation was not checking the group-id because the daemon and list groups have ID below 100. When I built and installed the 2.1.9 Ubuntu package without this patch, the Mailman code began checking the group-id and found a mismatch.
I would appreciate it if someone would confirm my conclusions. Thanks.
Your conclusion as I understand it is correct.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I have a client who is receiving messages from a Mailman list I run that aren't showing up as expected. The list is supposed to be converting to plain text and this works fine for me (I use Thunderbird). My client on the other hand was getting the messages with a non-plain text font. She uses Outlook. After much fumbling around I noticed that the encoding of these messages are reported as Central European by Outlook. If I manually change the encoding on these messages to West European the messages look as I would expect.
I cannot figure out why these messages are showing up with Central European encoding. All of the settings in Outlook are set to what I would expect for a US user. I can't find anything that would point to Outlook converting the message to Central European encoding. The same message received by me in Thunderbird show up correctly with Western encoding.
She is also receiving messages from other sources and they are showing up with the correct plain text font as set in Outlook. In seems that she is only having problems with messages from my Mailman server.
Does anybody have any guesses as to what might be happening?
Thanks,
Paul Navarre
Paul Navarre wrote:
I cannot figure out why these messages are showing up with Central European encoding. All of the settings in Outlook are set to what I would expect for a US user. I can't find anything that would point to Outlook converting the message to Central European encoding. The same message received by me in Thunderbird show up correctly with Western encoding.
She is also receiving messages from other sources and they are showing up with the correct plain text font as set in Outlook. In seems that she is only having problems with messages from my Mailman server.
Does anybody have any guesses as to what might be happening?
Not without seeing a message. Using your Tbird, select one of these messages as received by you from the list, then select 'Message Source' from the View menu. Then in the source view either select, copy and paste into a reply, all the headers of the message including the boundaries and part headers if the message is multipart, or select File->Save Page As and save it to a file with a .txt extension and attach that to a reply. If you wish, you may edit addresses, domains and message body for privacy, but we need to see the message headers and MIME structure if any of the message.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Barry Finkel -
Mark Sapiro -
Paul Navarre