php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78757 Default sendmail_path gets populated incorrectly when sendmail is not found
Submitted: 2019-10-29 00:35 UTC Modified: 2024-07-14 15:23 UTC
From: indrek at ardel dot eu Assigned: petk (profile)
Status: Closed Package: *Compile Issues
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: indrek at ardel dot eu
New email:
PHP Version: OS:

 

 [2019-10-29 00:35 UTC] indrek at ardel dot eu
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.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-10-29 17:24 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2019-10-29 17:24 UTC] cmb@php.net
Indeed, it seems PHP_PROG_SENDMAIL is set unconditionally[1].

[1] <https://github.com/php/php-src/blob/php-7.3.11/acinclude.m4#L2086>
 [2024-07-14 15:23 UTC] petk@php.net
-Status: Verified +Status: Closed -Assigned To: +Assigned To: petk
 [2024-07-14 15:23 UTC] petk@php.net
This has been fixed via https://github.com/php/php-src/pull/5548

and configure log enhanced via https://github.com/php/php-src/pull/14955
 [2024-07-14 20:00 UTC] git@php.net
Automatic comment on behalf of petk (author) and web-flow (committer)
Revision: https://github.com/php/php-src/commit/8e8dc40765ef50fb7a883b266abc51d2c69cd38b
Log: Fix #78757: Enhance sendmail log notice (#14955)
 [2024-09-09 12:49 UTC] git@php.net
Automatic comment on behalf of petk (author) and web-flow (committer)
Revision: https://github.com/php/php-src-security/commit/8e8dc40765ef50fb7a883b266abc51d2c69cd38b
Log: Fix #78757: Enhance sendmail log notice (#14955)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 02:01:28 2024 UTC