Bug #78916 [Ver]: php-fpm 7.4.0 don't send mail via mail()

From: Date: Fri, 06 Dec 2019 15:23:16 +0000
Subject: Bug #78916 [Ver]: php-fpm 7.4.0 don't send mail via mail()
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-17085@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78916&edit=1

 ID:                 78916
 Updated by:         nikic@php.net
 Reported by:        ilya at ilya dot pp dot ua
 Summary:            php-fpm 7.4.0 don't send mail via mail()
 Status:             Verified
 Type:               Bug
 Package:            Documentation problem
 Operating System:   systemd/linux
 PHP Version:        7.4.0
-Assigned To:        
+Assigned To:        bukka
 Block user comment: N
 Private report:     N

 New Comment:

Assigning bukka for his opinion on the topic.


Previous Comments:
------------------------------------------------------------------------
[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

------------------------------------------------------------------------
[2019-12-06 08:07:03] ilya at ilya dot pp dot ua

I have a policy of trying to implement as much functionality as possible using the basic features of
a programming language. I use third-party only when the necessary functionality is beyond the scope
of this programming language (for example, export to pdf or xls).

Sending mail is necessary for any programming language aimed at server-side web scripts.

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).

If the basic mail () function written in C has such problems, and a third-party function written in
PHP is better and safer, then why shouldn't the PHP developers rewrite it safely, possibly even
preserving its interface?
In C, can it be better and more productive, and most importantly, without third-party code?

Or am I not understanding something?

------------------------------------------------------------------------
[2019-12-06 07:48:42] fgfgfgfdf at somewhere dot com

what about trying to understand what's going on when using mail()?
the sendmail command forkend in the background with *root privileges*

do what you want, the "Lenart NotABag Pottering" gave you the capabilities to make your
system as unsecure as you want within /etc/systemd/system/servicename.service.d/

defaults have to be secure, if you know what you are doing which i doubt make it unsecure as you
want

------------------------------------------------------------------------
[2019-12-06 07:42:58] ilya at ilya dot pp dot ua

For 20 years we lived without systemd and without their limitations and everything was fine, but
Lenart NotABag Pottering came and brought its democracy to our sinful land ...

By default, NoNewPrivileges=false and in php 7.3.11 it is also disabled.
In the migration instructions for php 7.4, not a word about the need to coordinate reconfigure the
systemd file!

I am not saying that NoNewPrivileges=true is not necessary at all.
If there is another safe way to solve my problem without turning it off, I will only be glad. But
for now I do not know how.
I suspect that this could break any call to system().

As for mail() - it was there and remains the standard, basic, recommended way to send mail in php.
The only thing it is not suitable for mass mailings, which I know very well.

But if calling mail() is not safe this is a php bug.

------------------------------------------------------------------------


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


Thread (3 messages)

« previous php.doc.bugs (#17085) next »