I have a long discussion thread at the Mailman support group, https://www.mail-archive.com/search?l=mailman-users%40python.org&q=subject:%22%5C%5BMailman%5C-Users%5C%5D+IOError%5C%3A+%5C%5BErrno+13%5C%5D+Permission+denied+on+config.pck+in+Fedora+30%22&o=newest It's been pointed out that Fedora forces the effective group to run mailman as the group 'apache'. Here's a traceback: admin(28961): [----- Traceback ------] admin(28961): Traceback (most recent call last): admin(28961): File "/usr/lib/mailman/scripts/driver", line 118, in run_main admin(28961): main() admin(28961): File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 44, in main admin(28961): listinfo_overview() admin(28961): File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 104, in listinfo_overview admin(28961): mlist = MailList.MailList(name, lock=0) admin(28961): File "/usr/lib/mailman/Mailman/MailList.py", line 133, in __init__ admin(28961): self.Load() admin(28961): File "/usr/lib/mailman/Mailman/MailList.py", line 692, in Load admin(28961): dict, e = self.__load(file) admin(28961): File "/usr/lib/mailman/Mailman/MailList.py", line 655, in __load admin(28961): fp = open(dbfile) admin(28961): IOError: [Errno 13] Permission denied: '/var/lib/mailman/lists/ourlist/config.pck' admin(28961): Process effective group = apache admin(28961): [----- Python Information -----] admin(28961): sys.version = 2.7.16 (default, Apr 30 2019, 15:54:43) [GCC 9.0.1 20190312 (Red Hat 9.0.1-0.10)] admin(28961): sys.executable = /usr/bin/python2 admin(28961): sys.prefix = /usr admin(28961): sys.exec_prefix = /usr admin(28961): sys.path = ['/usr/lib/mailman/pythonlib', '/usr/lib/mailman', '/usr/lib/mailman/scripts', '/usr/lib/mailman', '/usr/lib/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/dist-packages'] admin(28961): sys.platform = linux2 admin(28961): [----- Environment Variables -----] admin(28961): SERVER_NAME: ourdomain admin(28961): HTTPS: on admin(28961): REMOTE_ADDR: 150.108.64.133 admin(28961): PYTHONPATH: /usr/lib/mailman admin(28961): REMOTE_PORT: 55541 admin(28961): REQUEST_SCHEME: https admin(28961): SCRIPT_NAME: /mailman/listinfo admin(28961): REQUEST_METHOD: GET admin(28961): HTTP_HOST: ourdomain admin(28961): SERVER_PORT: 443 admin(28961): SERVER_PROTOCOL: HTTP/1.1 admin(28961): QUERY_STRING: admin(28961): REQUEST_URI: /mailman/listinfo admin(28961): DOCUMENT_ROOT: /var/www/html Is there a way to handle this in the mailman.service file? I doesn't seem using suexec as noted in https://wiki.list.org/DOC/Apache+Suexec works either.
I have been working with the OP on this issue. To clarify, the issue appears to be that the OS is not honoring the SETGID bit on the compiled Mailman CGI wrappers even though the file system is mounted with defaults options. This causes the CGI scripts to be executed with effective group 'apache' rather than 'mailman'. Mailman's security model requires everything to run with effective group 'mailman'. The OP feels this issue may has started after dnf updated on June 30.
Hello, Thank you for reporting this issue. It's quite weird since there were not updates of mailman last 5 month or so. Have you tried to disable selinux and check if issue still exists? -- Pavel
selinux has always been disabled.
Also, this is not an issue with Mailman per se. Mailman's security model is based on everything being run as group 'mailman' and the 'mailman' group has all the requisite permissions. The Mailman processes themselves run as user:group mailman:mailman so they are not an issue. The issue here is the Mailman CGI's run by Apache. To enable this, there are compiles binary executable wrappers in the /usr/lib/mailman/cgi-bin directory. These have group 'mailman' and have the SETGID bit set so when apache runs one of thes processes, the process runs with effective group 'mailman'. What has happened is SETGID is no longer being honored for these processes and they are being run as effective group 'apache'. The issue is in the OS or in Apache, not in Mailman.
I could not reproduce this issue so far. Checked both fedora 30 and fedora rawhide installation and listinfo works fine. Can you provide exact reproduce steps please?
(In reply to Pavel Zhukov from comment #5) > I could not reproduce this issue so far. Checked both fedora 30 and fedora > rawhide installation and listinfo works fine. > Can you provide exact reproduce steps please? Well, sure, I just run 'dnf reinstall mailman' and straight away I get: Bug in Mailman version 2.1.29 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs or the web server logs. I disabled mod_security and mod_evasive to make sure those weren't causing the issue as well. What else can I provide?
(In reply to RobbieTheK from comment #6) > (In reply to Pavel Zhukov from comment #5) > > I could not reproduce this issue so far. Checked both fedora 30 and fedora > > rawhide installation and listinfo works fine. > > Can you provide exact reproduce steps please? > > Well, sure, I just run 'dnf reinstall mailman' and straight away I get: > Bug in Mailman version 2.1.29 > We're sorry, we hit a bug! > Please inform the webmaster for this site of this problem. Printing of > traceback and other system information has been explicitly inhibited, but > the webmaster can find this information in the Mailman error logs or the web > server logs. > > I disabled mod_security and mod_evasive to make sure those weren't causing > the issue as well. > > What else can I provide? It's good to know exact version of mailman package. Please provide mailman logs (/var/log/mailman/*) Apache's logs (/var/log/httpd/*) at least. I'd like to recommend you to check audit.log as well (It may contain sensitive information so don't share it in BZ unless you've checked it carefully).
Created attachment 1594654 [details] mailman logs rpm -q mailman mailman-2.1.29-6.fc30.x86_64 httpd logs: http://storm.cis.fordham.edu/~rkudyba/httpdlogs.tar.gz note the files is 186 MB as mod_security is a bit verbose.
Perhaps the contents of /usr/lib/systemd/system/mailman.service will be useful, note I changed the ExecStartPre=/bin/chmod 666 /var/log/mailman/error from the default. [Unit] Description=GNU Mailing List Manager After=syslog.target network.target [Service] ExecStartPre=/usr/lib/mailman/bin/mailman-update-cfg ExecStartPre=/usr/bin/install -m644 -o mailman -g mailman /usr/lib/mailman/cron/crontab.in /etc/cron.d/mailman ExecStartPre=/bin/touch /var/log/mailman/error ExecStartPre=/bin/chown mailman:mailman /var/log/mailman/error ExecStartPre=/bin/chmod 666 /var/log/mailman/error ExecStart=/usr/lib/mailman/bin/mailmanctl -s start ExecReload=/usr/lib/mailman/bin/mailmanctl restart ExecStop=/usr/lib/mailman/bin/mailman-update-cfg ExecStop=/usr/lib/mailman/bin/mailmanctl stop ExecStop=/bin/sh -c 'echo -e "# DO NOT EDIT THIS FILE!\n#\n# Contents of this file managed by /etc/init.d/mailman\n# Master copy is /usr/lib/mailman/cron/crontab.in" > /etc/cron.d/mailman' Type=forking [Install] WantedBy=multi-user.target
Note that this is not a Mailman issue per se. The issue is that apache runs the cgi wrappers in /usr/lib/mailman/cgi-bin/ as user:group apache:apache and the wrappers are compiled binary executables with SETGID and group mailman, but in spite of this they are running with effective group 'apache' and not 'mailman'.
Hi Mark, I understand it and I've read your comments in this bug and mailing list. However to blame apache we have to be sure it's a problem in software not in configuration. I've installed mailman on Fedora 30 created mailman list and started both httpd and mailman services. I can see mailman interface, listinfo, create list pages and no mailman errors. And honestly I don't see recent (<4 months) changes in httpd in Fedora 30 branch which could cause this issue.
See https://bugzilla.redhat.com/show_bug.cgi?id=1733359#c4 I am certainly not blaming Apache. I said "The issue is in the OS or in Apache, not in Mailman.". I think the OS (or its configuration) is much more likely. I'm just not ruling out Apache.
Ok. Reassigned to httpd then... @Lubos, any ideas?
(In reply to Pavel Zhukov from comment #11) > Hi Mark, > I understand it and I've read your comments in this bug and mailing list. > However to blame apache we have to be sure it's a problem in software not in > configuration. I've installed mailman on Fedora 30 created mailman list and > started both httpd and mailman services. I can see mailman interface, > listinfo, create list pages and no mailman errors. > And honestly I don't see recent (<4 months) changes in httpd in Fedora 30 > branch which could cause this issue. I'm hoping it's a configuration issue as well. It's just odd that it stopped working, we haven't checked in on it in a few months (2-3 perhaps) when it used to work. Did the logs provide anything useful? I would think others would be having this problem so perhaps it is something on our side. Anything else I can provide?
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Rebooting server helped.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.