Bug #78757 [NEW]: Default sendmail_path gets populated incorrectly when sendmail is not found

From: Date: Tue, 29 Oct 2019 00:35:08 +0000
Subject: Bug #78757 [NEW]: Default sendmail_path gets populated incorrectly when sendmail is not found
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-223495@lists.php.net to get a copy of this message
From:             indrek at ardel dot eu
Operating system: 
PHP version:      Irrelevant
Package:          *Compile Issues
Bug Type:         Bug
Bug description:Default sendmail_path gets populated incorrectly when sendmail is not found

Description:
------------
When sendmail cannot be found on the system during compile time, the
default config for PHP will be populated as if it was found.

If we take a look at
https://github.com/php/php-src/blob/c2f56d0546832abee24961daf47872ccebd52266/main/main.c#L714-L720
then placing an #error macro to the elif branch shows that
PHP_PROG_SENDMAIL seems to be defined regardless of whether it is
actually found on the system. If sendmail is found, then it's the path
of the executable, but when it isn't, then it will be an empty string.
To rule out the obvious, I do get checking for sendmail... no when
it's not installed, as expected. Test was performed in Debian Buster.

For cases where sendmail is not found, this results in default value
being an unusable sendmail_path =  -t -i instead of the expected
sendmail_path = /usr/sbin/sendmail -t -i, which in source currently
seems to be part of unreachable code.

A valid use case of sendmail not existing at the compile time would be
for instance Docker containers. If the consumer desires, they can
install sendmail on top of an existing PHP container, however for it to
currently work there, they would have to also override the sendmail_path
in configuration. In most cases sendmail will appear at
/usr/sbin/sendmail when installed, so including it by default would
spare anyone from explicitly configuring it.

As far as I can tell, this behavior has existed for a long time and thus
I am unable to pinpoint a version where it last time worked as expected.
Bug #43591 seems to be the original issue that in my opinion is on
point, but the response about register_globals seems too odd for me, so
I think this was dismissed incorrectly. I'd like for someone to take a
second look at it.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=78757&edit=1
-- 
Fix committed:                    https://bugs.php.net/fix.php?id=78757&r=fixed
Fixed in release:                 https://bugs.php.net/fix.php?id=78757&r=alreadyfixed
Need backtrace:                   https://bugs.php.net/fix.php?id=78757&r=needtrace
Need Reproduce Script:            https://bugs.php.net/fix.php?id=78757&r=needscript
Try newer version:                https://bugs.php.net/fix.php?id=78757&r=oldversion
Not developer issue:              https://bugs.php.net/fix.php?id=78757&r=support
Expected behavior:                https://bugs.php.net/fix.php?id=78757&r=notwrong
Not enough info:                  https://bugs.php.net/fix.php?id=78757&r=notenoughinfo
Submitted twice:                  https://bugs.php.net/fix.php?id=78757&r=submittedtwice
register_globals:                 https://bugs.php.net/fix.php?id=78757&r=globals
PHP version support discontinued: https://bugs.php.net/fix.php?id=78757&r=phptooold
Daylight Savings:                 https://bugs.php.net/fix.php?id=78757&r=dst
IIS Stability:                    https://bugs.php.net/fix.php?id=78757&r=isapi
Install GNU Sed:                  https://bugs.php.net/fix.php?id=78757&r=gnused
Floating point limitations:       https://bugs.php.net/fix.php?id=78757&r=float
No Zend Extensions:               https://bugs.php.net/fix.php?id=78757&r=nozend
MySQL Configuration Error:        https://bugs.php.net/fix.php?id=78757&r=mysqlcfg


Thread (3 messages)

« previous php.bugs (#223495) next »