Edit report at https://bugs.php.net/bug.php?id=78916&edit=1
ID: 78916
Updated by: bukka@php.net
Reported by: ilya at ilya dot pp dot ua
Summary: php-fpm 7.4.0 don't send mail via mail()
Status: Closed
Type: Bug
-Package: Documentation problem
+Package: FPM related
Operating System: systemd/linux
PHP Version: 7.4.0
Assigned To: bukka
Block user comment: N
Private report: N
New Comment:
Fixed in a suggested way. We can't really break mail function in the default unit no matter how
secure its usage is - that should be discussed somewhere else and it's not FPM business to
decide that. The default unit has to work for all the core parts.
Previous Comments:
------------------------------------------------------------------------
[2019-12-08 17:59:06] bukka@php.net
Automatic comment on behalf of bukka
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ac042f839f4c4a2b8241fa69f8f3b01766814f1e
Log: Fix bug #78916 (php-fpm 7.4.0 don't send mail via mail())
------------------------------------------------------------------------
[2019-12-08 17:57:39] bukka@php.net
Automatic comment on behalf of bukka
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ac042f839f4c4a2b8241fa69f8f3b01766814f1e
Log: Fix bug #78916 (php-fpm 7.4.0 don't send mail via mail())
------------------------------------------------------------------------
[2019-12-06 15:23:16] nikic@php.net
Assigning bukka for his opinion on the topic.
------------------------------------------------------------------------
[2019-12-06 11:57:52] sjon@php.net
> this is sonsense
No it's not. Nowhere does PHP have a dependency on sendmail - so it makes sense that settings
like CapabilityBoundingSet and NoNewPrivileges are secure by default, and only lists dependencies
FPM itself actually needs.
I do agree this could be mentioned on https://www.php.net/manual/en/migration74.other-changes.php
since this has become stricter in 7.4
------------------------------------------------------------------------
[2019-12-06 08:18:44] fgfgfgfdf at somewhere dot com
> I did not know that sendmail needed root privileges > to work (from the console, and from other scripts, > I always sent mail via sendmail from a regular > user without problems)
so be gald that you now learned about https://en.wikipedia.org/wiki/Setuid thanks to
systemd and it's capabilities to run services in a secure way
> then why shouldn't the PHP developers rewrite it safely
because the only safe way is to use smtp which typically needs configuration and authentication and
there is no reason to do so given that the gold standard fpr send mail from PHP is phpMailer for
many years (which can even use sendmail if the webserver is allowed to evelvate privileges
> Sending mail is necessary for any programming language > aimed at server-side web scripts
yeah, you can implement SMTP in wahtever language you want, phpMailer did that for PHP
so either sacrifice the security of your server and continue what you did all the years or now that
you learned about the security implications (fire up a root process from the webserver) stop demand
sacrifice security of the default install
the capabilities and NoNewPrivileges are fine as default, here we go *much* further
User=apache
Group=apache
AmbientCapabilities=CAP_IPC_LOCK CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_BIND_SERVICE
LockPersonality=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
RestrictNamespaces=yes
RestrictRealtime=yes
SystemCallArchitectures=x86-64
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot
@swap
ProtectSystem=strict
ProtectHome=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ReadWritePaths=/run/httpd
ReadWritePaths=/tmp
ReadWritePaths=/var/log
ReadWritePaths=/var/www
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=78916
--
Edit this bug report at https://bugs.php.net/bug.php?id=78916&edit=1