I need help setting up mailman in a chrooted OpenBSD environment. I've
copied the /usr/local/lib/mailman and /var/spool/mailman directories to
/var/www/mailman, as well as the modules it needed, but now I'm getting an
error that says:

Mailman CGI error!!! The Mailman CGI wrapper encountered
a fatal error. This entry is being stored in your syslog:
Failure to find group name for GID 67. Mailman
expected the CGI wrapper to be executed as group
"www", but the system's web server executed the
wrapper as GID 67 for which the name could not be
found. Try adding GID 67 to your system as "www",
or tweak your web server to run the wrapper as group
"www".

I believe that a chrooted apache drops the user name and just holds onto the
user id. Can anyone help me out with this? I really need this installed
and kinda need to keep the chroot. If I need to start over with a fresh
installation of mailman, that's not a problem. Any and all help would be
GREATLY appreciated!

Search Discussions

  • Mark Sapiro at Sep 7, 2007 at 2:04 pm

    Patrick Valencia wrote:
    I need help setting up mailman in a chrooted OpenBSD environment. I've
    copied the /usr/local/lib/mailman and /var/spool/mailman directories to
    /var/www/mailman, as well as the modules it needed, but now I'm getting an
    error that says:

    Mailman CGI error!!! The Mailman CGI wrapper encountered
    a fatal error. This entry is being stored in your syslog:
    Failure to find group name for GID 67. Mailman
    expected the CGI wrapper to be executed as group
    "www", but the system's web server executed the
    wrapper as GID 67 for which the name could not be
    found. Try adding GID 67 to your system as "www",
    or tweak your web server to run the wrapper as group
    "www".

    I believe that a chrooted apache drops the user name and just holds onto the
    user id. Can anyone help me out with this? I really need this installed
    and kinda need to keep the chroot. If I need to start over with a fresh
    installation of mailman, that's not a problem. Any and all help would be
    GREATLY appreciated!

    I suggest you try install Mailman from source
    <http://sourceforge.net/projects/mailman> and configure it with

    --prefix=/var/www/mailman

    and

    --with-cgi-gidg

    as well as the appropriate --with-mail-gid.

    Alternatively, there may be a way to set the expected cgi group in
    whatever package you installed and you might be able to set that to 67.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Patrick Valencia at Sep 8, 2007 at 12:59 am
    I configured it as such:

    ./configure --prefix=/var/www/mailman --with-mail-gidg --with-cgi-gidg
    --with-username=_mailman --with-groupname=_mailman

    (using the _mailman user & group from the port install) and I still get the
    same error:

    Failure to find group name for GID 67. Mailman
    expected the CGI wrapper to be executed as group
    "www", but the system's web server executed the
    wrapper as GID 67 for which the name could not be
    found. Try adding GID 67 to your system as "www",
    or tweak your web server to run the wrapper as group
    "www".

    I was pretty sure that this would force mailman to look for '67' as the
    group, but it seems to still be looking for 'www'.

    On 9/7/07, Mark Sapiro wrote:

    Patrick Valencia wrote:
    I need help setting up mailman in a chrooted OpenBSD environment. I've
    copied the /usr/local/lib/mailman and /var/spool/mailman directories to
    /var/www/mailman, as well as the modules it needed, but now I'm getting an
    error that says:

    Mailman CGI error!!! The Mailman CGI wrapper encountered
    a fatal error. This entry is being stored in your syslog:
    Failure to find group name for GID 67. Mailman
    expected the CGI wrapper to be executed as group
    "www", but the system's web server executed the
    wrapper as GID 67 for which the name could not be
    found. Try adding GID 67 to your system as "www",
    or tweak your web server to run the wrapper as group
    "www".

    I believe that a chrooted apache drops the user name and just holds onto the
    user id. Can anyone help me out with this? I really need this installed
    and kinda need to keep the chroot. If I need to start over with a fresh
    installation of mailman, that's not a problem. Any and all help would be
    GREATLY appreciated!

    I suggest you try install Mailman from source
    <http://sourceforge.net/projects/mailman> and configure it with

    --prefix=/var/www/mailman

    and

    --with-cgi-gidg

    as well as the appropriate --with-mail-gid.

    Alternatively, there may be a way to set the expected cgi group in
    whatever package you installed and you might be able to set that to 67.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Patrick Valencia at Sep 8, 2007 at 1:16 am
    Matter of fact, when I configure it, the DCGI_GROUP="\"www\"" and so does
    the DMAIL_GROUP. I think it's taking the 67 as a gid and finding the group
    it belongs to. I'm still not exactly sure how it can't see the gid when it
    goes to run the cgi script I thought it would be able to, especially since
    the set_gid bit is enabled. Would it help if I added a /var/www/etc/group
    file with 67 mapped to 'www'?
    On 9/7/07, Patrick Valencia wrote:

    I configured it as such:

    ./configure --prefix=/var/www/mailman --with-mail-gidg --with-cgi-gidg
    --with-username=_mailman --with-groupname=_mailman

    (using the _mailman user & group from the port install) and I still get
    the same error:

    Failure to find group name for GID 67. Mailman
    expected the CGI wrapper to be executed as group
    "www", but the system's web server executed the
    wrapper as GID 67 for which the name could not be
    found. Try adding GID 67 to your system as "www",
    or tweak your web server to run the wrapper as group
    "www".

    I was pretty sure that this would force mailman to look for '67' as the
    group, but it seems to still be looking for 'www'.

    On 9/7/07, Mark Sapiro wrote:

    Patrick Valencia wrote:
    I need help setting up mailman in a chrooted OpenBSD environment. I've
    copied the /usr/local/lib/mailman and /var/spool/mailman directories to
    /var/www/mailman, as well as the modules it needed, but now I'm getting an
    error that says:

    Mailman CGI error!!! The Mailman CGI wrapper encountered
    a fatal error. This entry is being stored in your syslog:
    Failure to find group name for GID 67. Mailman
    expected the CGI wrapper to be executed as group
    "www", but the system's web server executed the
    wrapper as GID 67 for which the name could not be
    found. Try adding GID 67 to your system as "www",
    or tweak your web server to run the wrapper as group
    "www".

    I believe that a chrooted apache drops the user name and just holds onto the
    user id. Can anyone help me out with this? I really need this installed
    and kinda need to keep the chroot. If I need to start over with a fresh
    installation of mailman, that's not a problem. Any and all help would be
    GREATLY appreciated!

    I suggest you try install Mailman from source
    < http://sourceforge.net/projects/mailman> and configure it with

    --prefix=/var/www/mailman

    and

    --with-cgi-gidg

    as well as the appropriate --with-mail-gid.

    Alternatively, there may be a way to set the expected cgi group in
    whatever package you installed and you might be able to set that to 67.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Sep 8, 2007 at 1:31 am

    Patrick Valencia wrote:
    Matter of fact, when I configure it, the DCGI_GROUP="\"www\"" and so does
    the DMAIL_GROUP. I think it's taking the 67 as a gid and finding the group
    it belongs to.

    That's right. See my other reply.

    I'm still not exactly sure how it can't see the gid when it
    goes to run the cgi script I thought it would be able to, especially since
    the set_gid bit is enabled.

    See
    <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.016.htp>.

    The setgid bit sets the effective group, but for security reasons the
    wrapper checks the original group by resolving the original gid to a
    name and seeing if that name matches what it was told to expect. If it
    can't resolve the original gid to a name, it gives the error.

    Would it help if I added a /var/www/etc/group
    file with 67 mapped to 'www'?

    If that would allow the wrapper to resolve gid 67 to the name "www",
    then yes, that would do it.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Patrick Valencia at Sep 8, 2007 at 1:43 am
    Ok, so the /var/www/etc/group file works, but now it's giving me another
    error:

    No such file or directory.

    It mentions storing the output into a syslog, but from checking apache's
    error_log and access_log, I don't see anything useful. It shows
    /mailman/admin getting a 200 response, which means OK, but that's all it
    says. And since it's chrooted, I'm pretty sure it can't reach whatever
    syslog it's trying to. If I knew which log it was, I could make an entry in
    the chroot jail, and check, but I'm not sure what files it would be needing
    outside the chroot anyway.

    BTW, I really appreciate your help Mark!
    On 9/7/07, Mark Sapiro wrote:

    Patrick Valencia wrote:
    Matter of fact, when I configure it, the DCGI_GROUP="\"www\"" and so does
    the DMAIL_GROUP. I think it's taking the 67 as a gid and finding the group
    it belongs to.

    That's right. See my other reply.

    I'm still not exactly sure how it can't see the gid when it
    goes to run the cgi script I thought it would be able to, especially since
    the set_gid bit is enabled.

    See
    <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.016.htp>.

    The setgid bit sets the effective group, but for security reasons the
    wrapper checks the original group by resolving the original gid to a
    name and seeing if that name matches what it was told to expect. If it
    can't resolve the original gid to a name, it gives the error.

    Would it help if I added a /var/www/etc/group
    file with 67 mapped to 'www'?

    If that would allow the wrapper to resolve gid 67 to the name "www",
    then yes, that would do it.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Sep 8, 2007 at 1:50 am

    Patrick Valencia wrote:
    Ok, so the /var/www/etc/group file works, but now it's giving me another
    error:

    No such file or directory.

    Where do you see this error?

    Is there an entry in Mailman's error log (/var/www/mailman/logs/error I
    think in your case)?


    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Sep 8, 2007 at 1:24 am
    Patrick Valenciawrote:
    I configured it as such:

    ./configure --prefix=/var/www/mailman --with-mail-gidg --with-cgi-gidg
    --with-username=_mailman --with-groupname=_mailman

    (using the _mailman user & group from the port install) and I still get the
    same error:

    Failure to find group name for GID 67. Mailman
    expected the CGI wrapper to be executed as group
    "www", but the system's web server executed the
    wrapper as GID 67 for which the name could not be
    found. Try adding GID 67 to your system as "www",
    or tweak your web server to run the wrapper as group
    "www".

    I was pretty sure that this would force mailman to look for '67' as the
    group, but it seems to still be looking for 'www'.

    I too thought that would be the case, but closer examination of
    configure says that when you give it --with-cgi-gid=<numeric>, it
    looks up the group name that corresponds to the numeric gid and uses
    the name.

    Also, the specific "Failure to find group name for GID 67" message from
    the wrapper comes from the inability to find a group name for the
    numeric gid under which it was invoked, and the expected group "www"
    is the compiled in group name that came from looking up 67 at
    configure time.

    The bottom line is I think you have two options.

    Figure out how to make the web server (cgi-gid) and the MTA (mail-gid)
    invoke the respective wrappers with some gid that can be resolved to a
    name inside the chroot jail, and configure those as the expected
    groups,

    or modify the code in src/common.c to either bypass the group tests or
    change them to something that will work.

    You might also look at
    <http://mail.python.org/pipermail/mailman-users/2007-August/058157.html>
    and the containing thread and the results of
    <http://www.google.com/search?hl=en&safe=off&q=site%3Amail.python.org++inurl%3Amailman++chroot>.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Patrick Valencia at Sep 8, 2007 at 6:34 pm
    Ohh... *slaps forehead* python isn't in the chrooted environment. But
    wouldn't the cgi executable require python to output the error message?
    Should I just install another copy of python into
    /var/www/usr/local/bin/python? Do you know much about chrooting
    applications? This isn't really a mailman issue if that's all it is, but I
    want to be sure that's all it is.
    On 9/8/07, Mark Sapiro wrote:

    Patrick Valencia wrote:
    When trying to make install in the src directory I get this error:

    :/var/www/mailman-2.1.9/src$ sudo make install
    for f in admindb admin confirm create edithtml listinfo options private
    rmlist roster subscribe; do exe=/var/www/mailman/cgi-bin/$f;
    /usr/bin/install -c -m 755 $f $exe; chmod g+s $exe; done
    install: /var/www/mailman/cgi-bin/admindb: No such file or directory
    *** Error code 71

    Stop in /var/www/mailman-2.1.9/src (line 114 of Makefile).

    I don't really understand why ...

    So I reconfigured and changed the Makefile in the mailman-2.1.9 directory
    then make clean/make/installed it and then overwrote it with the same from
    the src directory, and both times I'm still getting the same error. I'm
    thinking it doesn't have to do with the gid. I think it's trying to access
    a different file outside the chroot. However, I'm pretty much all out of
    ideas at this point.

    If it's not the setregid, its the call to run the driver script which
    tries to run the python executable (at the path configure found) with
    arguments of the path to scripts/driver and the name of the cgi
    (e.g.admindb). Maybe it's python it can't find.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Sep 8, 2007 at 6:55 pm

    Patrick Valencia wrote:
    Ohh... *slaps forehead* python isn't in the chrooted environment. But
    wouldn't the cgi executable require python to output the error message?

    No. The CGI executable wrapper is a compiled/bound C program (mostly
    because SETGID doesn't work with 'scripts'). So the wrapper executes
    just fine without Python until it tries to call Python to execute the
    driver script.

    Should I just install another copy of python into
    /var/www/usr/local/bin/python? Do you know much about chrooting
    applications? This isn't really a mailman issue if that's all it is, but I
    want to be sure that's all it is.

    I probably know less than you about chrooting applications. I *think*
    that just installing python so it's accessable from the jail will fix
    it, but you'll need to rerun configure with the --with-python= option
    to point to the right python.

    Ideally, you'd run configure chrooted. The whole idea behind autoconf
    is it tailors the package to the environment. If configure can find/do
    things that the executable package can't find/do because it runs in a
    different (chrooted) environment, the whole purpose of configure is
    subverted.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedSep 5, '07 at 8:21p
activeSep 8, '07 at 6:55p
posts10
users2
websitelist.org

2 users in discussion

Mark Sapiro: 5 posts Patrick Valencia: 5 posts

People

Translate

site design / logo © 2022 Grokbase