PHP shell_exec cannot find environment variable - php

I have added this line PATH DEFAULT=${PATH}:~/bin/ to the ~/.pam_environment
This allows me to call ffmpeg from command line without path which is obviously in ~/bin/ dir so everything works fine as long as im ussing command line.
But if try to run the exact same command from php all i get is sh: ffmpeg: not found
And the code is
shell_exec("ffmpeg 2>&1");
So from my very little experiance with linux (in this case Ubuntu to be specific) i guess apache has no access to pam_environment or ~/bin
What can i do to make this work?

look at the output of phpinfo(), it has a section with all environment variables it sees. then look at your webserver configuration, maybe it's sanitizing the environment, or maybe the init script which starts your webserver does it.
and is the account the webserver is running under using PAM at all?

Related

Running complicated ROS shell command through php

I'm trying to run a ROS shell program on the server through php on Ubuntu 14.04. I have tried using system, exec, shell_exec but nothing happens and I don't get any output. The system call is the following:
echo shell_exec("/opt/ros/indigo/bin/rosrun gazebo_ros spawn_model -database Part_A -gazebo -model Part_A");
What are the limitations of using system or exec to run any shell command through php on a server?
I don't care as much about the output of the command as for its execution. I think the problem has to do with the fact that PHP doesn't have any PATH like shell does so it can't find any applications without specifying the exact location. How can I make PHP se the same PATH shell does?
The problem was that the apache user and the environment in which the bash commands are running are not set up correctly. I followed the instructions from this answer but instead of using "source" I used "." and instead of using the source.bash file I used the source.sh file. I also set all the environment variables that had to do with ros or gazebo using the putenv() function.

PuTTy command in PHP doesn't work, web service to restart Raspberry Pi

I am trying to do simple web service in PHP (I use Laravel) to restart and shutdown my raspberry pi.
I tried in my PHP service call something like this:
exec("putty -ssh pi#192.168.0.12 -pw myPassword -m D:\workspace\CPS\public\ssh\restart.txt");
In my restart.txt I have simple command sudo shutdown -r now
but when I call my web service in Advanced Rest Client Application (Chrome addon), my request is processing and never ending. In command line this works properly.
I thought that the problem is with running PuTTy directly in PHP and I do some changes and create .bat file with the following content:
echo off
putty -ssh pi#%1 -pw %2 -m %3
I start this batch script like this:
exec("D:\workspace\CPS\public\ssh\restart.bat 192.168.0.12 myPassword D:\workspace\CPS\public\ssh\restart.txt");
...but result is the same. I changed my web service to GET method and call service in the browser like page but nothing change.
I haven't any error/exception in log files and in console. I also checked the system log but nothing found.
Am I doing something wrong or missed something? It is possible or there is a better way to achieve this?
Currently I run it on Windows 7 and XAMPP. I will do second version for Linux in future and decide in code which command should I run depends on current environment.
Update
I forgot to wrote, all required users have permissions to execute files in my (...)/ssh directory
Try to use:
echo system("D:\workspace\CPS\public\ssh\restart.bat 192.168.0.12 myPassword D:\workspace\CPS\public\ssh\restart.txt");
to get output. May be you find something error.
And you need to check safe_mode options in your php.ini file (like disable_functions and safe_mode_exec_dir).
And try to use FULL path to your putty.exe file. Webserver work's in another directory, than your bat file.

cURL not working in Windows Task Scheduler

I've a PHP script that uses cURL to perform certain tasks. At the moment, I have the script running every 10 minutes. This is what I'm running via Windows Task Scheduler.
C:\wamp\bin\php\php5.4.3\php.exe -f C:\wamp\www\autoscripts\index.php
However, for some reason, whenever the argument quoted above is run through the command line, I get the error "Fatal error: Call to undefined function curl_init()". The script works perfectly when I access it via the browser. Is there any reason why PHP isn't able to access the cURL extension via the command line?
Most likely running from command line does not use any ini file that loads the extensions. Open phpinfo() from the browser, copy path to loaded ini file and change your task to:
C:\wamp\bin\php\php5.4.3\php.exe -c "C:\path\to\php.ini" -f C:\wamp\www\autoscripts\index.php
Figured it out. Basically, on WampServer, there are TWO php.ini files that you need to be aware of.
C:\wamp\bin\php\php5.4.3\php.ini
C:\wamp\bin\apache\apache2.2.22\bin\php.ini
Forgot that the command line uses a different ini file than the web server. :(

PHP exec() not working properly

I am having difficulty with the PHP exec() function. It seems to not be calling certain functions. For instance, the code echo exec('ls'); produces no output whatsoever (it should, there are files in the directory). That main reason this is a problem for me is that I'm trying execute a .jar from a PHP exec() call.
As far as I know I'm calling the java program properly, but I'm not getting any of the output. The .jar can be executed from the command line on the server. (For the record, it's an apache server).
My php for the .jar execute looks like this:
$output = array();
exec('java -jar testJava.jar', $output);
print_r($output);
All I get for output from this exec() call is Array().
I have had success with exec() executing 'whoami' and 'pwd'. I can't figure out why some functions are working and some aren't. I'm not the most experienced person with PHP either, so I'm not too sure how to diagnose the issue. Any and all help would be appreciated.
The reason why you are not able to execute ls is because of permissions.
If you are running the web server as user A , then you can only ls only those directories which have permissions for user A.
You can either change the permission of the directory or you can change the user under which the server is running by changing the httpd.conf file(i am assuming that you are using apache).
If you are changing the permissions of the directory, then make sure that you change permissions of parent directories also.
To change the web server user, follow following steps:
Open the following file:
vi /etc/httpd/conf/httpd.conf
Search for
User apache
Group apache
Change the user and group name. After changing the user and group, restart the server using following command.
/sbin/service httpd restart
Then you will be able to execute all commands which can be run by that user.
EDIT:
The 'User' should be a non-root user in httpd.conf. Apache by default doesnot serve pages when run as root. You have to set user as a non-root user or else you will get error.
If you want to force apache to run as root, then you have to set a environment variable as below:
env CFLAGS=-DBIG_SECURITY_HOLE
Then you have to rebuild apache before you can run it as root.
I have found the issue - SELinux was blocking PHP from accessing certain functions. Putting SELinux into permissive mode has fixed the issues (although, I'd rather not have to leave SELinux in permissive mode; I'd rather find a way of allowing certain functions if I can).
I have a solution:
command runs from console, but not from php via exec/system/passthru.
The issue is the path to command. It works with the absolute path to command
So that:
wkhtmltopdf "htm1Eufn7.htm" "pdfIZrNcb.pdf"
becomes:
/usr/local/bin/wkhtmltopdf "htm1Eufn7.htm" "pdfIZrNcb.pdf"
And now, it's works from php via exec
Where command binary you can see via whereis wkhtmltopdf
Tore my hair out trying to work out why PHP exec works from command line but not from Apache. At the end, I found the following permissions:
***getsebool -a | grep httpd*** ---->
**httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_sys_script_anon_write --> off**
USE: setsebool -P httpd_ssi_exec 1
SEE: https://linux.die.net/man/8/httpd_selinux
Your problem is not an execution issue but the syntax of the exec command. The second argument is always returned as an array and contains a single line of the output in each index. The return value of the exec function will contain the final line of the commands output. To show the output you can use:
foreach($output as $line) echo "$line\n";
See http://php.net/manual/en/function.exec.php for details. You can also get the command's exit value with a third argument.

illegal command error code 127 in php exec function

I am using this php code:
exec("unrar e file.rar",$ret,$code);
and getting an error code of illegal command ie 127 ... but when I am using this command through ssh its working ... because unrar is installed on the server ... so can anyone guess why exec is not doing the right stuff?
Try using the direct path of the application (/usr/bin/unrar of whatever), it sounds like php can't find the application.
If you have chrooted apache and php, you will also want to put /bin/sh into the chrooted environment. Otherwise, the exec() or passthru() will not function properly, and will produce error code 127, file not found.
Since this comes up as a top answer in google, I wanted to share my fix:
The simple fix I had was to disable safe_mode in the php.ini file
; Safe Mode
; http://www.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode
safe_mode = Off
thanx all for your response!!
I tried this
//somedir is inside the directory where php file is
chdir("somedir");
exec("/home/username/bin/unrar e /home/path/to/dir/file.rar");
and now it returned no exit code ... oher commands are doing file .. i tried mkdir etc .. :s
Just in case somebody else still gets this problem, take a look at the post here:
http://gallery.menalto.com/node/2639#comment-8638
Quote:
I found the problem. The problem was my security-paranoid OpenBSD. When upgrading from 3.1 to 3.2 they added:
Apache runs chroot'd by default. To disable this, see the new -u option.
The chroot prevented Apache from accessing anything outside of a directory, so I moved everything into the apache directory including netpbm. Everything was accessible and executable, but I guess it was still in some sort of "safe mode" because the exec() always returned 127.
Anyway, running httpd with the -u option went back to the less secure non chroot'd apache startup, which allowed the exec() to work again.
ohkiee guyz thanx ... and yes there might be some errors with $PATH ... but with given full path its working :)
exec("/home/user/bin/unrar e /home/user/xxx/yyy/file.rar");
I did not find the solution for my problem of the same type so sharing what was the cause of it in my Linux setup.
For whatever reason I needed an apache module loaded before other modules and so apache was started with LD_PRELOAD. As exec inherits the environment of the parent process LD_PRELOAD was used for starting the exec-ed program (through sh). Now the preloaded module uses some bindings to apache functions and of course they are not to be present in sh. The result of the php exec was an exit status of 127. The solution was to have in my php file a putenv("LD_PRELOAD") that gets executed before any exec calls.

Categories