More specifically, the NoNewPrivileges=true forbids the postfix's postrop setgid to be enforced. As a result, the php's mail function blocks and the journal shows a bunch of these : sept. 25 11:52:08 underground postfix/postdrop[25341]: warning: mail_queue_enter: create file maildrop/894573.25341: Permission denied sept. 25 11:52:09 underground postfix/postdrop[24987]: warning: mail_queue_enter: create file maildrop/260416.24987: Permission denied sept. 25 11:52:18 underground postfix/postdrop[25341]: warning: mail_queue_enter: create file maildrop/894758.25341: Permission denied sept. 25 11:52:19 underground postfix/postdrop[24987]: warning: mail_queue_enter: create file maildrop/260629.24987: Permission denied sept. 25 11:52:28 underground postfix/postdrop[25341]: warning: mail_queue_enter: create file maildrop/895009.25341: Permission denied sept. 25 11:52:29 underground postfix/postdrop[24987]: warning: mail_queue_enter: create file maildrop/260838.24987: Permission denied ... As a workaround, overriding it with NoNewPrivileges=false in /etc/systemd/system/apache2.service.d/override.conf seems enough.
candrews: Care to comment?
I believe that mod_php is being used here - please correct me if I'm wrong. Apache is moving away (arguably, has already moved away) from in process CGI and scripting modules, such as mod_php. There are many reasons, including scalability, security, and maintainability (you have to match the Apache threading model with the PHP threading model compiling and configuring each to match the other). See https://wiki.apache.org/httpd/php What's happening is that Apache is hardened to not allow the privilege escalation that PHP (running in mod_php therefore in the Apache process) is requesting in its mail function. Anyone except users using in process CGI/scripting would want such privilege escalations to be denied - for those users, such an attempt indicates that an attacker has taken control of the Apache process. We could disable this hardening in Apache, but since most people don't use this approach (and it's discouraged), I don't think that's the right solution. I recommend the reporter to switch to another approach to interface Apache with PHP, such as php-fpm, which is more maintainable, scalable, and secure. I think the right solution is to resolve this issue as WONTFIX (the workaround the reporter provided to override the settings can of course continue to be used for those users who choose to do so).
I confirm mod_php is being used. All that really makes sense, and of course I don't ask for disabling hardening altogether. The workaround is good enough for my use case until I can switch to fpm. I understand nothing could/should be done on the apache side. But maybe a postinst notice should be added on the php side when building with apache2 support to inform the user that this configuration is becoming unsupported and that major features like sending mail may break.
Bug 600292 reports a similar breakage with suexec.
The only hardening option set in Fedora is PrivateTmp=true https://src.fedoraproject.org/rpms/httpd/blob/rawhide/f/httpd%40.service I would then simply drop all the other extra hardening to prevent problems like this.
I think it's better to be secure by default, and make it simple for the sysadmin to override as necessary.
I hit the same bug after migrating from a OpenRC server instance to systemd setup. After several days of having a broken server I reverted back to OpenRC. The best ideas I found were https://linux.m2osw.com/snapwebsites-postfixpostdrop18189-warning-mailqueueenter-create-file-maildrop25937318189-permission https://github.com/systemd-cron/systemd-cron/issues/75#issuecomment-927384865 What a relief after having maildrop working again! I had to to do after systemd install: mkdir /etc/openvpn/server/ mv /etc/openvpn/foo.conf /etc/openvpn/server/ and revert that when moving back. Also systemd did not enable by default network on my eth0^H^H^H^Henp0s3 interface via dhcp at least (there are no scripts which would migrate the /etc/conf.d/net contents at all?), so I lost network connection to the server altogether. KVM console rocks! And yes, I had to add the "init=" argument to grub to boot up. Of course, using "emerge --nodeps" to override the systemd being required by this and that was necessary with a bit of praying if unistalling sysvinit+openrc and recompile of almost all packages keeps the system working upon the reboot. Oh yeah, reboot did not understand -k argument when moving from openrc to systemd, so the machine did NOT reboot but hung up. KVM power off was necessary, as ACPI events like ctrl+alt+del were not handled anymore. Tiny nit pick: If you make in /etc/systemd/network/50-static.network lowercase "g" instead of "G" in the word Gateway, you end up with default gateway 0.0.0.0 , what a great deal. Luckily the server and me survived all the blind recompiles of all system packages, procmail+postfix+dovecot+openvpn+openssh+libpam+pambase+sysvinit+openrc+baselayout+udev+util-linux+procps, with a few isntall with "emerge --nodeps" to overcome the blockers.
