CSF unable to detect disable_functions correctly!

[Ohm J]

ok I found something relate to CB 2832

http://files.directadmin.com/services/custombuild/2.0/custombuild/build

perl -pi -e 's|"html_errors=0\\n"|"html_errors=0\\n"\n\t"disable_functions=\\n"|g' ./sapi/cli/php_cli.c

This explain why CLI not show disable_functions
But I think, this should have option to clear by default or not. ( Must be editable)

 

[tarsiran]

We are still looking for a solution to this problem because we are still receiving errors in the firewall

 

[smtalk]

So what does it do then ?,
Why are there mixed results? ,
As said, I have checked 2 Almalinux 8.5 servers , one of them has no problems but other has this "bug" using the same CB version !

I'm not sure what the "bug" is? Regarding the difference - that other server likely did not have PHP re-build after CB 2.0 rev. 2832.

 

[Richard G]

but can't detect with php - i

Try using it without the quotes, so not:
php -i | grep "disable_func"
but
php -i | grep disable_func
shouldn't make any difference but one never knows.

 

[tarsiran]

Try using it without the quotes, so not:
php -i | grep "disable_func"
but
php -i | grep disable_func
shouldn't make any difference but one never knows.

Thanks, but it has no effect on the result and the problem still exists. I tested on 2 servers

 

[Richard G]

2832 - Clear disable_functions on command-line PHP calls

What's the benefit of removing that? Seems it causes confusion (also with CSF).

Isn't PHP is rebuild on updates?
So I also don't understand the mixed results then. Because on our servers Centos 7 and Almalinux 8.5 we also do get the output.

 

[smtalk]

What's the benefit of removing that? Seems it causes confusion (also with CSF).

These settings may cause confusion as well, because command-line PHP would provide different values than in php.ini:

html_errors=0
register_argc_argv=1
implicit_flush=1
output_buffering=0
max_execution_time=0
max_input_time=-1

Benefit is the same as for the settings above - command line execution would have unexpected issues other way. For example, composer, "bin/magento", pecl complaining on some functions disabled, while it adds no benefit.

Regarding "confusion" with CSF - there are multiple other ways to check what's used for non-commandline SAPI of PHP. One of them could be php --ini and checking the actual configuration then.

Isn't PHP is rebuild on updates?

It is, but are you sure you've re-built it with CustomBuild 2832 or newer?

Thank you!

 

[tarsiran]

These settings may cause confusion as well, because command-line PHP would provide different values than in php.ini:

html_errors=0
register_argc_argv=1
implicit_flush=1
output_buffering=0
max_execution_time=0
max_input_time=-1

Benefit is the same as for the settings above - command line execution would have unexpected issues other way. For example, composer, "bin/magento", pecl complaining on some functions disabled, while it adds no benefit.

Regarding "confusion" with CSF - there are multiple other ways to check what's used for non-commandline SAPI of PHP. One of them could be php --ini and checking the actual configuration then.


It is, but are you sure you've re-built it with CustomBuild 2832 or newer?

Thank you!

I also tested the last version of Direct Admin that I installed on my new server two days ago. There was a problem that I sent screenshots in previous posts.

 

[Richard G]

because command-line PHP would provide different values than in php.ini

Oke I thought it would just use the php.ini values from the default php version (php1 in DA) then.
But I understand the point of view due to the other things, thanks for explaining.

It is, but are you sure you've re-built it with CustomBuild 2832 or newer?

I'm sure I had a php update recently so that should be after 2832. Don't know the exact date of 2832. But it should change after the next php update then anyway right?
I don't mind that it did not change on my servers yet though.

 

[smtalk]

But it should change after the next php update then anyway right?

Yes, it should

 

[tarsiran]

Yes, it should

Can you give a solution how to fix the firewall error problem?

 

[smtalk]

Can you give a solution how to fix the firewall error problem?
View attachment 5224

It mentions php.ini file checked, but it doesn't seem to actually check it. I'd suggest reporting it to firewall developers.

 

[Richard G]

but it doesn't seem to actually check it.

Yes it does, but it seems to only check the former one in /usr/local/lib when using 1 php version. So it does not check the correct location anymore.

It might be brought to attention of the devs of CSF. Maybe it's an idea to automatically create a symlink from /usr/local/lib/php.ini to the php.ini from the version which is set as php1?
I don't know which would work best. Just a thought.

 

[evgeni22385]

have same issue, then where the bug ? does they disabled or i am in the risk right now
running centos 7.9 , php7.4 and php8 .
in php.ini showing they disabled but csf no value.

 

[Richard G]

ave same issue, then where the bug ?

It's not really a bug. CSF is just not looking at the correct place. So don't bother what CSF says. If you have it set in the php.ini files for all php versions then you're fine and not at risk.

If you want to doublecheck, put a phpinfo.php file in your domain folder and open it and you will see.

 

[MacLeod]

I have the same little problem on a Almalinux8 based server & cant wait to see this "problem" solved

 

[Richard G]

For it to be solved, somebody has to go over to CSF forums and ask them to fix it.

 

[MacLeod]

Have done this today...... : https://forum.configserver.com/viewtopic.php?t=12503

 

[uteliux]

So no solution? same here :/

but CSF shows

 

[Zhenyapan]

@uteliux CSF recommend you to DISABLE this functions, and you shows .ini where they really not disabled. To disable some function you must put it to list of disabled functions.