echo system("/usr/bin/whoami", $ret);
echo $ret;
PHP 4.3.9 on Apache 2.0.52, CentOS 4.5. Safe mode is off, I can run programs as the apache user account from the command line, but all programs run from PHP fail with exit code 127.
See if /usr/bin/whoami exists, and is executable (and readable, mode xx5) by anyone.
See php.ini on doc_root and user_dir, if those are set they can limit what you can execute.
If your Apache or PHP is chrooted, you need to put the application to execute into the chroot.
If there's some other security system or RBAC running on the machine, see dmesg or log files in /var/log/.
Don't forget to use &$ret instead of $ret.
See PHP's exec() and passthru(), different functions might work for different situations.
Know that there's a different php.ini for Apache, and a different one for cli use.
Related
Is there any reason why I can not complied files in PHP's shell_exec/exec/system function?
Example of something that does work in command line and PHP's shell_exec function:
<?php
$data = shell_exec("ls");
echo $data;
?>
Example of something that does not work in PHP's shell_exec function but will work in command line (I can confirm that):
<?php
$data = shell_exec("./c-compiled-file argv1 argv2 argv3");
echo $data;
?>
Is there anything I can do on my server so this will work? I've looked everywhere and no solutions I found fixed the problem. The compiled file is in the same directory as the PHP script as well, it just won't execute it. Also if you're asking, yes I have tried this with SSH2 and it still will not execute.
Also PHP is not in safe mode and NO functions are disabled.
Some common glitches when executing external commands from PHP that work fine from shell:
Command uses relative paths but PHP is launched from an arbitrary location:
Use getcwd() / chdir() to get/set working directory
PHP and shell run with different user credentials. This is often the case when PHP runs through a web server.
PHP and shell run different commands. Many people call stuff like exec("foo $bar") and doesn't even check what "foo $bar" contains.
No error checking is done. The bare minimum is to capture and print standard output, standard error, status code and, of course, all PHP error messages including warnings and notices.
You can redirect stderr to sdtout
You can use a PHP function that allows to capture more information, such as exec()
The web server is disallowed to execute the command at operating system level.
Lookout for SELinux or similar tools.
Just a guess, but the binary you're trying to execute might not have the proper permissions. Prepeding it with ./ in the command line forces it to execute, but PHP probably strips that for security purposes. Try this:
chmod +x c-compiled-file
You want to use system in the second case, and not shell_exec.
system executes an external program and displays the output.
shell_exec executes a command via shell and returns the complete output as a string.
and for good measure:
exec simply executes an external program.
Furthermore you want to make sure your external program is executable and (though you have stated it, I'll restate this) has execute permissions for the user which is running the web server. You also want to make sure the directory your external program is running in has the ability to write to its directory or /tmp or whatever output directory you have set.
Finally you should always use absolute paths for executing things like this in cron or php or whatever... so don't use ./c-compiled-file argv1 argv2 argv3, but instead use /home/username/c-compiled-file argv1 argv2 argv3 or whatever the full path is.
Like many others I have problem with shell_exec() function in PHP. I have safe mode disabled and disabled_functions deleted from php.ini.
If I run php script from terminal (php print.php) it's working perfectly but if I run it from web browser nothing happens.
Here is the scipt:
<?php
$output = shell_exec('lp print.php');
echo "<pre>$output</pre>";
?>
Please help me. I'm running PHP 5.3.10 on Apache2. My OS is Ubuntu Server 12.4. Here is the phpinfo page: http://testni-server.info/info.php
Progamming language PHP allows one to limit executing of external commands via configuration directive safe_mode_exec_dir. This directive should contain full path to a directory conatining programs which PHP script can run. If the script tries to execute a command not located in this directory, the command is not executed. This configuration directive is active only if safe mode is enabled, which means more and sometimes unwanted restrictions to users. PHP has no known possibility to limit executing of external commands with disabled safe mode. Teherefore, here is a patch adding special directive exec_dir straightly into PHP. This directive is very similar to safe_mode_exec_dir, but safe mode has not to be enabled.
This patch limits or corrects the behavior of these functions:
exec()
passthru()
proc_open()
shell_exec()
system()
popen()
is_executable()
The patch was created for purposes of limit execution of external commands of users on a multidomain apache server, first for PHP version 4.2.1. The patch was sent to PHP developers so it could be a part of PHP, but no one of PHP developers was interested in. On the other side, some PHP users wanted this patch, therefore this site was created.
Your command line (CLI) PHP might be using a different working directory and/or path than the CGI one. Try defining the working directory (containing the lp command) explicitly with chdir() before calling shell_exec().
I have a PHP script that needs to run from command line. One of the function it calls is socket_create.
In php.ini, I have included the following in order to get that function working (see the comment on http://www.php.net/manual/en/sockets.installation.php):
extension=php_sockets.dll
How do I run the script from command line such that it doesn't complain that socket_create is an unknown function? Does PHP CLI actually respect what's in php.ini? I thought it was supposed to, but I do get errors when running it via CLI and no errors when running it via the browser.
UPDATE: by the way, I'm testing this out: https://github.com/nicokaiser/php-websocket. I assume that the server needs to be executed via command line.
A different php.ini file may apply when running php on the CLI rather than as a web server module. You appear to be using Windows, so I'm not sure where this file may be, but it could provide a clue; look for several php.ini files in your disk and see if one of them applies to CLI invocations.
it's a bit complicated. :-) I have a website written in PHP that needs to call an external program written in .NET, running under Mono. It calls the program with:
/path/mono /path/executable arguments...
as per usual (I also tried to put this into a bash script and call the script itself from PHP).
As far as I can tell, everything is set up as required. Mono itself running all right, executable (or script) with executable rights, owners are all right. The correct setup can also be ascertained from the fact that if I issue the command line above (or call the script mentioned) from a command line on the server (Debian Lenny), everything works perfectly, my executable is executed without error.
But, if PHP calls the same (using exec(), system() or any other variant), I immediately get an exit code of 6 from Mono and my executable is not run at all (in order to test it, I use a "Hello World" executable that does nothing but emits a single output line and returns 0). Compiled without any additional dependency, just a real "Hello Word". It's absolutely sure that this program doesn't return the exit code 6, it must come from Mono but I couldn't find it documented anywhere.
I can call anything else from PHP, so it's not safe mode or any similar restriction that would keep me from executing external programs from PHP.
Thanks for any idea...
Try to execute mono from the command line but with the user running the webserver (www-data or apache).
ej.
#su apache
$/path/to/mono /path/to/program.exe
The common problems that I have using exec is a different environment variables (look if is bash or sh what apache is using), permissions to the user/group of apache, etc.
When I call /usr/local/bin/pdftk from PHP in Apache (via shell_exec(), exec(), system(), etc.), it returns the SYNOPSIS message as expected.
When I call /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten via shell_exec(), nothing returns.
When I copy and paste the exact same string to the same path in the shell (as the apache user), the output.pdf file is generated as expected.
Moving the pdftk command into a PHP shell script (shebang is #!/usr/bin/php) and executing it with php script.php works perfectly.
Calling that shell script (with its stderr redirected to stdout) from PHP in Apache (via shell_exec(script.php);) results in this line:
sh: line 1: 32547 Segmentation fault /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten 2>&1
Whenever I run the script from the command line (via PHP or directly), it works fine. Whenever I run the script through PHP via Apache, it either fails without any notification or gives the SegFault listed above.
It's PHP 4.3.9 on RHEL4. Please don't shoot me. I've set memory to 512M with ini_set() and made sure that the apache user had read/write to all paths (with fopen()) and by logging in as apache ...
Just went and checked /var/log/messages to find this:
Oct 4 21:17:58 discovery kernel: audit(1286241478.692:1764638):
avc: denied { read } for pid=32627 comm="pdftk" name="zero"
dev=tmpfs ino=2161 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:zero_device_t tclass=chr_file
NOTE: Disabling SELinux "fixed" the problem. Has this moved into a ServerFault question? Can anybody give me the 30 second SELinux access controls primer here?
php-cli & php-cgi (or the module, depends on what your server uses) are different binaries. They don't even have to share the same version to live happily side by side on your server. They also may not share the same configuration. Increasing memory usually does nothing to help Segfaults. Points to check:
Are they the same version?
Do they have the same settings (consult the *.ini locations loaded in the phpinfo(); output, and possibly the whole output itself), if not: try what happens if you alter the one for your webserver to the one for the cli as far as possible.
Segfaults occur more in extensions then in the core afaik, and sometimes seemingly unrelated. Try to disable unneeded extensions one by one to see if the problem goes away.
Still no success? You may want to run apache with gdb, but I have no experience with that, it might tell you something though.
No luck? Recompile either the module of cgi your webserver uses.
It's PHP 4.3.9 on RHEL4. Please don't shoot me.
I feel more sad for you then anger, we're beyond the 5.3 mark, come over, it's a lot more happy here.