I have a PHP shell on a Linux red-hat server with user privileges. I'm trying to symlink the root directory and still its impossible using ln -s or even symlink() in PHP.
I have seen that PHP DL function is disabled like this picture:
I used a php.ini in my current directory witch contain this string:
safe_mode=OFF
disable_functions=NONE
and it didn't disabled, so what to do?
The dl function, and the ability to dynamically load PHP extensions, has been removed from all PHP SAPIs, with exception of CLI SAPI, since PHP 5.3 (and 7.0 in php-fpm).
Warning This function was removed from most SAPIs in PHP 5.3.0, and was removed from PHP-FPM in PHP 7.0.0.
Source php.net/dl
So unless you're running PHP 5.2, there is no use for that function in a Web SAPI. You shouldn't be trying to dynamically load your extensions at runtime in a web environment anyway. It usually doesn't make any sense and can result in a lot of edge cases. Most of these edge cases are moot in a CLI environment, but matter to a web environment.
As for overriding disable_functions you want to make sure you're editing the correct php.ini file and checking phpinfo() from the correct SAPI. Remember that the PHP running from CLI and your Apache/web are two different binaries, that can load different configuration files. So you should have a look at phpinfo() from the correct one to find the "Loaded configuration" file to edit. You always need to restart PHP for these loaded configurations to take effect. Just keep in mind that dl() likely is removed from any current supported version of PHP.
Related
I'm using PHP 7.2.10 on my laptop that runs on Windows 10 Home Single Language 64-bit operating system.
I've installed Apache/2.4.34 (Win32) and PHP 7.2.10 using the latest version of XAMPP.
Today, I come across the following statement from PHP Manual :
The configuration file (php.ini) is read when PHP starts up. For the
server module versions of PHP, this happens only once when the web
server is started. For the CGI and CLI versions, it happens on every
invocation.
Above text has created following doubts in my mind :
What does exactly mean by first sentence? It's only saying that
The configuration file (php.ini) is read when PHP starts up.
But it's not saying who does read it? Is it the PHP parser or the Apache web server? Or something else? Please explain to me.
In case of CGI and CLI versions, why the php.ini file is read again and again and who reads it?
In case of CGI and CLI versions, the process of reading the php.ini file happens on every invocation? What does mean by this sub-clause every invocation?
How many php.ini files can possibly be exist there? If such more than one files exist then what's the role of every such php.ini file?
P.S. : All the above questions have been asked to me in a technical interview.
P.S. : I know that php.ini is the main configuration file with all the configuration setting on the local machine.
The PHP compiler/parser.
Because PHP does not persist for command line invocations, so it is read at run-time.
Every time you call a PHP script, either CGI or CLI.
More than one, typically 2. One for the web server and one for CLI/CGI.
Search on DDG and in here didn't get any interesting results. I've heard they're different, but I want to know what makes them different and what advantage is there in having two different configurations ?
EDIT : Yes, I am running them both from the CLI.
phpinfo() is a language function that will display its output regardless of whether the script that it's executed in is called through the web SAPI or from CLI;
php -i is purely a command line switch to get information about PHP from the command line.
Why different configurations for web sapi and for CLI? Because you might have different requirements; often devs will run long command line scripts and don't want the web sapi timeout applied, similarly with memory settings; and max file/post size ini settings are meaningless for CLI, so why bother having them in the cli ini file when they're only needed for the web?
Depending on your server distribution, there may be separate php.ini
files for the command line and web server.
Source:
Pro PHP
Patterns, Frameworks, Testing and More
By Kevin McArthur
https://books.google.pl/books?id=CpUhDavmgSMC&pg=PT410&lpg=PT410&dq=%22php+-i+command%22&source=bl&ots=iljmNZ96ZU&sig=iRrX8_UjJWiOzlLtRz0zwJOtQJc&hl=pl&sa=X&ved=0ahUKEwicoq6NrsLLAhVjQZoKHeSSA8wQ6AEIPDAE#v=onepage&q=%22php%20-i%22&f=false
php -i gives you the same info you got using phpinfo() but:
can use a different set of INI files than your web server (so you can different values for some configuration parameters)
it formats the data in a console-friendly way (no html tags, for example)
Edit:
don't digged the sources, but I can bet both uses the same code to extract their info .. in other words php -i is "calling phpinfo()" in a console-aware way and context
If i make changes in php-ini:
when does php react?
is it possible, that I get other data in phpinfo()
than php realy uses?
If you are using PHP as an Apache module, you will have to restart the httpd service to have PHP re-read php.ini, or changes will not be taken into account.
From this PHP manual entry.
The configuration file (php.ini) is read when PHP starts up. For the server module versions of PHP, this happens only once when the web server is started. For the CGI and CLI versions, it happens on every invocation.
I am using php version 5.3 on media temple's grid server, however when I call a file using exec() the page is executing in PHP version: 4.4.9
The reason I am using exec() is to process the file in the background.
This is probably a simple question, but how do I manually set the PHP version to 5.3 for this file without using .htaccess?
Thanks.
The PHP interpreter you invoke via exec() is often a CGI version installed on the server as /usr/bin/php. You need to find out if a more contemporary version is available and then call the interpreter explicitly:
exec("/usr/bin/php-5.3 your-script.php &");
# or just adapt your scripts shebang #!/usr/bin/php5
(Just an example, the filename will be different. Also you can usually leave out the path. It's mostly just security relevant for setuid binaries.)
You might find out about other versions via print_r(glob("/usr/bin/php*")). But asking your hoster might be a better idea.
I need to install or use php on a windows 2003 server that already has php 5.2.0.0 installed due (I think) to setting up symantec backup exec. I don't want to interfere with backup exec's php.ini settings - and would rather be able to control my own configuration of php.
searching for php shows that php.exe and other php files are currently installed in
c:\program files\symantec\backup exec\
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
There is no PHPRC entry in the server properties > environment variables and I'm pretty sure that the php.exe location is not included in the PATH variable. ...unless the actuall install location is different from the c:\program files\symantec\backup exec\ dir.
Any suggestions on how to proceed?
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
What makes you say that :) I've run separate PHP versions on the same machine side by side and not run into bother.
AFAIK the Symantec install should not conflict with your own installation, nor should the separate php.ini files conflict with each other.
[Response to comment]
First thing to note is that I have no experience of Backup Exec or what it uses PHP for. I'm guessing it uses it for its own internal stuff and doesn't spread itself over the OS. Test this by searching for php.ini and php DLLs on the file system. I'm betting it's all quite self contained. PHP searches for the config file as noted here: PHP Site . As you note, BE hasn't set the PHPRC variable. Check it hasn't used those Registry entries either. On a different tack, has BE installed an admin site already on IIS? If so, check the IIS Web Service Extensions to make sure it hasn't already registered the PHP ISAPI dll or PHP CGI exe. IF not, I think you should be okay for your new install.
To be on the safe side, do a manual PHP install as illustrated here: PHP Site. That way, you know exactly what you have installed, and can easily remove the files again if they cause a problem. I can't imagine a problem here that would require you to reinstall BE.