I am trying to run a command line file conversion using open office.
openoffice pdf filename.doc 2>&1
when i execute in command line as root it works fine and the file is converted. However when i pass the above command in a PHP file as apache user, it does not execute.
I tried all three PHP command line execution:
$command_output=system($command_line,$rtnval);
$command_output=exec($command_line,$rtnval);
$command_output=passthru($command_line,$rtnval);
Also,
echo print_r($rtnval);
echo print_r($command_output);
$rtnval returns 1 and $command_output 1. I am confused unable to know what is the linux (centos) response to above command passed. It is very frustration because unable to know what the system response when i try to execute the command.
I also included /etc/suders permission for apache to run the open office command.
apache ALL: (ALL) NOPASSWD: /path/to/openoffice
still the command is not execute in PHP as apache user.
What am i missing for PHP as apache user not to execute this command?
It could be that openoffice is not in PATH. Try to execute it with the full path.
To run your command as if you were the apache user, just try this in a shell:
# switch to superuser
sudo su -
# then switch to the apache user
su - www-data
You will find yourself in a quite restricted shell, from which it is usually not possible to start openoffice. Indeed, it requires a lot of environment, that would be unsafe to completely set up for apache anyway.
AFAIK, better create a dedicated user that is allowed to run your command (eg a regular "www-runner" user), then "su" to it from PHP. Other security measures include chroot'ing the dedidacted user, or using apparmor to limit what and where it is allowed to run. In any case, never let www-data run something as root by adding www-data to the sudoers: this is way too dangerous!
You can also have a look at libapache2-mod-suphp (a suid apache module to run php scripts with the owner permissions).It is easier to use than the dedicated suEXEC apache beast (http://httpd.apache.org/docs/2.0/suexec.html). The latter really is not for a quick fix ;)
It is possible that your php in apache runs in safe mode or what's it called, in which system() function and alike are disabled.
This answer, actually, assumes that what you call "running as apache user" is in fact running in apache environment, whatever it is.
Related
I have a page thats called form a browser which at the end needs to run one command as root. I am very well aware of the security implications of running shell_exec commands from the browser, so I have locked down my sudoers file for "apache all no password" to the one command:
apache ALL = (ALL) NOPASSWD: /usr/sbin/rndc
I have made my PHP page hard-coded so no part of the command is run from user-accessible inputs.
This process just refreshes the config for Bind9 (named) by issuing
shell_exec("/usr/sbin/sudo /usr/sbin/rndc reload");
However, it seems this does not run, but when I have make /bin/bash the default shell for apache and as apache, this process runs when I try it in apache shell:
[root#localhost zones]# su - apache
-bash-4.2$ /usr/bin/sudo /usr/sbin/rndc reload
server reload successful
My whole PHP code:
<?php
error_reporting(E_ALL);
$result = shell_exec("/usr/bin/sudo /usr/sbin/rndc reload");
print_r($result);
?>
I get no responses. Any ideas? SELinux is now set to permissive.
turned out to be the require_ttl parameter in my sudo files. Apache was erring in /var/log/httpd/error_log.
Thats to those who viewed :)
Can anybody help me? I'm using sphinx searcher, but i have many databases. I dynamically controll them (change the sphinx config file ), but after i add an index to the config file sphinx needs to be restarted. I have created an bash script for doing this (stop shpinx, start it, indexer --rotate --all ) and when i run the script from terminal it is ok, but when i run from apache server it is not working. How can i do this without changenig the owner of the apache server to root ( it will decrease the security of my server )?
How can i do this without changenig the owner of the apache server to root
How about sudo? Put something like this in your sudoers...
apache ALL= NOPASSWD: /path/to/script command
The catch is to make sure that the script cannot be exploited... as it is running as root... ie is read-only + exec for apache, ensure that commands/switches you send to the script are sanity checked.
I hope that helps,
Kind Regards,
Nick
I actually try to laucnh a gnome-term with a php script, seems i have some problems with the users www-data;
my script make only a ls -l command in a directory (is just for a test) and i run it with a php page in my local-web site.
here the gnome-terminal command in my bash script (he run perfectly when i double-click on him) :
gnome-terminal --working-directory=/opt/cuckoo -x bash -c "ls -l"
and here is the call on the php-page :
system("/my/path/to/the/script/script.sh");
i have some echo in my script and i see them in the php page after i try to run the script with the php.page.
i think www-data don't have the right to do so i give the ownership of the script with the chown command, and at last a try the sudo visudo command and make the script execute like the user www-data is root (with NO PASSWD arg)
But i can't open the terminal and make a ls at last, i try with exec too, and show the result with $ouput butthe result is the same as well.
At last my question is : Php can really run a terminal or maybe a fool myself^^? Thanks for taking time to rescure me ;)
PHP can run everything, but depends who spawns it. Forget just running X apps from a web server - you'll need more than just executing them (permissions, DISPLAY and Xauth settings). Read more about the X clients and architecture.
Probably the right place to ask this is at SuperUser, since the problem is not in the coding itself.
I tried to compile my latex file in php script, but it can't call xelatex.
In php script:
system("/usr/bin/whoami");
system("/usr/bin/xelatex foo.tex 2>&1");
output:
myuser
sh: 1: /usr/bin/xelatex: not found
But in my terminal:
$ /usr/bin/whoami
=> myuser
$ /usr/bin/xelatex foo.tex
This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009/Debian)
...(successful output)...
I run php as myuser, and pass system() absolute path. And I turn safe_mode off. Why can't I still execute external programs?
Finally I contacted my system administrator and found the problem. The machine is in a NFS, so the apache and login shell is on different machines. There is no xelatex on the machine where apache is running.
Check the permission of the directory from where you running you PHP code. check for myuser permissions
just for verification try it with root.
Hope this help
Are you sure it's not the file 'foo.tex' which it is unable to find? Try having the shell output to a file, e.g. system("/usr/bin/xelatex ./foo.tex > ./test.out"); and see what luck you get then.
I have a script in /var/www/myscript.sh which creates folders and runs the command svn update for my projects. I need to execute this script by calling it in a PHP file in the browser (i.e. Localhost/test.php). I tried using functions shell_exec() and exec() but those did not work. I ran my shell script in terminal with su www-data && ./myscript.sh and it worked. What else am I missing?
<?php
$output = shell_exec("./myscript.sh");
?>
Update 5/4/2011:
I added www-data ALL=(ALL) NOPASSWD:ALL to /etc/sudoers and it works, but this is very insecure. Is there another way to do this?
Several possibilities:
You have safe mode enabled. That way, only exec() is working, and then only on executables in safe_mode_exec_dir
exec and shell_exec are disabled in php.ini
The path to the executable is wrong. If the script is in the same directory as the php file, try exec(dirname(__FILE__) . '/myscript.sh');
You might have disabled the exec privileges, most of the LAMP packages have those disabled. Check your php.ini for this line:
disable_functions = exec
And remove the exec, shell_exec entries if there are there.
Good Luck!
Residuum did provide a correct answer to how you should get shell exec to find your script, but in regards to security, there are a couple of points.
I would imagine you don't want your shell script to be in your web root, as it would be visible to anyone with web access to your server.
I would recommend moving the shell script to outside of the webroot
<?php
$tempFolder = '/tmp';
$webRootFolder = '/var/www';
$scriptName = 'myscript.sh';
$moveCommand = "mv $webRootFolder/$scriptName $tempFolder/$scriptName";
$output = shell_exec($moveCommand);
?>
In regards to the:
i added www-data ALL=(ALL) NOPASSWD:ALL to /etc/sudoers works
You can modify this to only cover the specific commands in your script which require sudo. Otherwise, if none of the commands in your sh script require sudo to execute, you don't need to do this at all anyway.
Try running the script as the apache user (use the su command to switch to the apache user) and if you are not prompted for sudo or given permission denied, etc, it'll be fine.
ie:
sudo su apache (or www-data)
cd /var/www
sh ./myscript
Also... what brought me here was that I wanted to run a multi line shell script using commands that are dynamically generated. I wanted all of my commands to run in the same shell, which won't happen using multiple calls to shell_exec(). The answer to that one is to do it like Jenkins - create your dynamically generated multi line of commands, put it in a variable, save it to a file in a temp folder, execute that file (using shell_exec in() php as Jenkins is Java), then do whatever you want with the output, and delete the temp file
... voila
If you are having a small script that you need to run (I simply needed to copy a file), I found it much easier to call the commands on the PHP script by calling
exec("sudo cp /tmp/testfile1 /var/www/html/testfile2");
and enabling such transaction by editing (or rather adding) a permitting line to the sudoers by first calling sudo visudo and adding the following line to the very end of it
www-data ALL=(ALL) NOPASSWD:/bin/cp /tmp/testfile1 /var/www/html/testfile2
All I wanted to do was to copy a file and I have been having problems with doing so because of the root password problem, and as you mentioned I did NOT want to expose the system to have no password for all root transactions.