Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 595086 - >=www-servers/apache-2.4.23-r1: systemd hardening breaks php mail function
Summary: >=www-servers/apache-2.4.23-r1: systemd hardening breaks php mail function
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Apache Team - Bugzilla Reports
Depends on:
Reported: 2016-09-25 10:23 UTC by Cédric Schieli
Modified: 2021-10-18 20:53 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Cédric Schieli 2016-09-25 10:23:02 UTC
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.
Comment 1 Mike Gilbert gentoo-dev 2016-09-26 01:18:33 UTC
candrews: Care to comment?
Comment 2 Craig Andrews gentoo-dev 2016-09-29 02:52:20 UTC
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

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).
Comment 3 Cédric Schieli 2016-09-29 08:18:55 UTC
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.
Comment 4 Russell Yanofsky 2016-11-20 14:31:46 UTC
Bug 600292 reports a similar breakage with suexec.
Comment 5 Pacho Ramos gentoo-dev 2021-02-12 14:28:28 UTC
The only hardening option set in Fedora is 

I would then simply drop all the other extra hardening to prevent problems like this.
Comment 6 Mike Gilbert gentoo-dev 2021-04-28 19:33:21 UTC
I think it's better to be secure by default, and make it simple for the sysadmin to override as necessary.
Comment 7 Martin Mokrejš 2021-10-18 20:53:32 UTC
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

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/
lowercase "g" instead of "G" in the word Gateway, you end up with default gateway , 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.