Well, i have this program i need to run via either functions however it is located on my dekstop (this ubuntu 11.04).
I moved it to /home/Username, but no dice.
I run
$blah = exec('sudo | echo mypassword | /home/server1/program commandhere', $test);
var_dump($test);
var_dump($blah); ?>
The output is nothing.
I was told if i wanted to run it via sudo i needed to add the Apache user which is www-data to the sudoers list, i added it, but no luck again.
Basically, i've tried A LOT of things, it just wont run. Why?
EDIT:
If i paste that into the terminal it works great, just not with exec,system nor passtrhu.
Use echo mypassword | sudo -S instead.
It also depends on which user has sudo privileges. If you want to run this from the apache process, you need to give the apache user sudo privileges as well.
Also, just to clarify, the command should be:
echo mypassword | sudo -S /home/server1/program commandhere
Look into your security log. Not sure where this is on Ubuntu, possibly /var/log/secure or /var/log/messages. I'm betting that you find a message there similar to sudo requires a TTY, or sorry, you must have a TTY to run sudo indicating that sudo is configured not to work without a real interactive shell. That is, sudo won't permit you to use it in a script or to be called by an external program.
I recently dealt with this issue myself while trying to bind a Gnome keyboard shortcut to a sudo command.
If this is the case, you'll need to comment out the following line in /etc/sudoers
#Defaults requiretty
Related
I get this error when running a program from www-data.
Error
sudo: no tty present and no askpass program specified
But I have added the following to sudo visudo
www-data ALL = NOPASSWD: /var/bin/poppler-0.65.0/build/utils/pdfimages
The path /var/bin/poppler-0.65.0/build/utils/pdfimages is correct.. I have tested it from a terminal.
Command
sudo /var/bin/poppler-0.65.0/build/utils/pdfimages -list
data/scan_voucher/17.pdf
As you said that already setting up sudo visudo correctly, I will first take a look at Tarun Lalwani links, specially the part about disable requiring tty in your sudoers :
Defaults !requiretty
Try to do the same command but with flag -S actived (sudo -S yourcommand)
The -S (stdin) option causes sudo to read the password from the
standard input instead of the terminal device.
If it doesn't work for you, you can try a trick that seems to work like this one (from here):
echo '' | sudo -S your_command
That will send an empty password to first prompt to enter password.
How are you executing this from PHP? Try with:
#exec("sudo /var/bin/poppler-0.65.0/build/utils/pdfimages -list data/scan_voucher/17.pdf");
Hope that it helps!
I have next result of command sudo -u www-data echo $PATH in terminal:
/home/denis/node-v0.12.0/bin:/home/denis/node-v0.12.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
I have next result in PHP if I run command echo `echo \$PATH`:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PATH in terminal and in PHP is different. I don't understand why.
Running the command literally as given
sudo -u www-data echo $PATH
the $PATH is expanded by your shell before doing a sudo (and show your $PATH). However, if you quoted this properly, it could be deferred into the sudo'd user, and expose a different problem.
Unless you make special provision for this (an option to sudo, which may/may not work), environment variables such as PATH are reset to system defaults when using sudo. For further discussion see
How to keep Environment Variables when Using SUDO
How do I make sudo preserve my environment variables?
I am running CentOS 6, as httpd is executed as user 'apache'. For security reasons, I want to use sudo to be executed via exec as user 'aq':
<?php exec("/usr/bin/sudo -u aq somescript.sh",$output,$return_val);?>
With visudo I have added the following line:
apache ALL = (aq) NOPASSWD: ALL
Furthermore I temporary gave apache as login shell (/bin/bash), to be able to test
/usr/bin/sudo -u aq somescript.sh
directly which worked.
php exec fails as $return_val delivers a '1' if sudo is invoked.
Comment out this line from /etc/sudoers
Defaults requiretty
I'v tested your case in few ways ant this one gives me success.
So I want to execute the following command in my php script:
exec("/path/to/command");
Because it is the www-data user who runs php scripts, i currently can not run this command.
I have read something about suexec being able to run a command as if it was a different user. I find it rather difficult to understand how this works.
I have already installed suexec and edited the /etc/apache2/suexec/www-data file and added:
/home/user_to_run_command/script.php
I have also edited /etc/apache2/sites-enabled/000-default and added:
SuexecUserGroup user_to_run_command user_to_run_command
Am I missing anything?
suEXEC will work only when PHP is executed in CGI mode but not if PHP is running as an apache2
module. I guess you are running it as a module.
An alternative might be to transfer the ownership to the desired user and then set the suid bit:
chown desired_user your.program
chmod u+s your.program
Now when executing your.program it has permissions as if it where executed by it's owner. Follow the wiki article that I've linked for more information.
Side note: This will work with binaries only (not with shell scripts as they where executed by the shell binary which has no suid bit set)
I had the same problem and finally found a solution which as far a I can see is both safe and simple. A disadvantage of this method is that you have to take care of security updates when they are published.
What we are gonna do is make our own special shell which we chown and SUID to the user which we want the task to perform. To remain safe this user should be just an ordinary user without extensive system rights and place the script somewhere others are not allowed. Now we let php execute a script which uses this special shell and all command within this script will be executed as the chosen user.
In practice:
sudo mkdir /usr/lib/specialshell
sudo chown user_who_may_run_command:root /usr/lib/specialshell
sudo chmod 700 /usr/lib/specialshell
sudo cp /bin/perl specialperl
sudo chown user_to_run_command:usergroup_to_run_command specialperl
sudo u+s specialperl
sudo mv specialperl /usr/lib/specialshell
Now we make a script named command.script containing:
#!/usr/lib/specialshell/specialperl
$ENV{"PATH"} = "/usr/bin";
system("/path/to/command");
and from php code we use:
exec("/path/to/command.script");
et voila, no code change, just the name of command in php.
edit: works only with perl as shell, so changed bash to perl and put the shell somewhere safe
Here's my command:
sudo /usr/local/bin/jpegoptim --max=50 /home/someuser/public_html/reports/images/r121662.jpg
This command is supposed to compress an image. I tried running this command using backtick operator and shell_exec, neither will work. The file doesn't compress.
But this command runs when I run it directly in the shell logged in as someuser. I've modified sudoers to accept the command without requiring a password. The file is compressed when I run it in the shell.
Apache is configured to run with suPHP, and the PHP files belong to someuser as well. I've further ensured this by writing a test php script just saying system(id); and running it in the browser. That tells me that the script is indeed being run by someuser.
Also, safe_mode is off.
EDIT: Ok, I got it to output the error
sudo: sorry, you must have a tty to run sudo
Now, what does it mean?!
Thanks to Catalin , I was able to get an output. It said sudo: sorry, you must have a tty to run sudo which required requiretty to be disabled for someuser. That is the best solution I got, if there's a way to disable requiretty for a single user calling a single command, please let me know.
sudo typically requires terminal input (i.e., must have a tty) as it will attempt to ask the user for a password before allowing you to execute a command. Do you really need to use sudo to run the command? Try removing the sudo.
Try sudo -S to see if setting it to read the password from stdin (even though it doesn't need one) will bypass the test for a tty.