The chroot() doesn't get properly enabled/disabled when building SAPIs

[petk]

Description

The following code:

<?php
// check-chroot.php
if(function_exists('chroot')) {
    echo 'chroot() exists';
} else {
    echo 'chroot() not available';
}

Resulted in this output when building like this:

./buildconf
./configure --disable-embed --enable-litespeed
make -j$(nproc)

./sapi/litespeed/php check-chroot.php
# chroot() not available (which is ok by current design)

And resulted in this output when building like this:

./buildconf
./configure --enable-embed --enable-litespeed
make -j$(nproc)

./sapi/litespeed/php check-chroot.php
# chroot() exists (probably not ok)

But I would probably expect this output instead:

./buildconf
./configure --enable-embed --enable-litespeed
make -j$(nproc)

./sapi/litespeed/php check-chroot.php
# chroot() not available

There is a check for relatively dangerous chroot() function in ext/standard/config.m4, where ENABLE_CHROOT_FUNC constant gets defined depending on the selected SAPI:

AC_DEFINE(ENABLE_CHROOT_FUNC, 1, [Whether to enable chroot() function])

However, this is one of the parts that complicates the PHP build process. To get proper SAPIs, they all need to be build separately according to current design.

I'm just noting this bug for possible future reference. I'm not sure yet how to fix this better. Because disabling chroot() function might seem more appropriate in the C code directly in the main/main.c (however, this is probably not good fix yet):

--- a/main/main.c
+++ b/main/main.c
@@ -2223,6 +2223,10 @@ zend_result php_module_startup(sapi_module_struct *sf, zend_module_entry *additi
                }
        }
 
+       if (strcmp(sapi_module.name, "cli") != 0 && strcmp(sapi_module.name, "cgi-fcgi") != 0 && strcmp(sapi_module.name, "phpdbg") != 0 && strcmp(sapi_module.name, "embed") != 0) {
+               zend_disable_functions("chroot");
+       }
+
        /* disable certain classes and functions as requested by php.ini */
        zend_disable_functions(INI_STR("disable_functions"));
        php_disable_classes();

PHP Version

PHP 8.1+

Operating System

*nix

[bukka]

I agree it makes sense to disable it in SAPI runtime rather than during the build. Maybe it would be just better to define it directly by SAPI and just expose some common internal function for that. We already do something similar for apache_request_headers which is defined in FPM and Apache handler (even though that one has got different implementation). The advantage of that approach is that we don't need a runtime check in module start up.