I want to run a PHP script from chromium-browser which will print a file. The file is located in /tmp folder on the Raspberry Pi. The file is copied from the server using SAMBA. The script has shell_exec command which attempts to do something with the file. The script works from the command line but not through the browser (chromium). I run the latest Stretch version of Raspbian.
I suspect it is something to do with permissions but I do not know where the problem is located. I have previous image Jessie with similar setup and functionality and it works. I compared all the permissions on both systems and they are exactly the same but I must be missing something.
Here is the PHP script:
<?php
header("Access-Control-Allow-Origin: *");
shell_exec("sudo lpr -P printerName /tmp/sample.pdf");
shell_exec("rm /tmp/sample.pdf");
?>
Here are related permissions:
drwxrwxrwt 15 root root 4096 Nov 23 16:17 tmp
drwxr-xr-x 12 root root 4096 Nov 3 13:58 var
-rwxrw-rw- 1 nobody nogroup 320855 Nov 23 15:31 sample.pdf
Related
I have a question about the exec function on PHP 7.0.
I write a shell script to copy/sync the files and log the details into a log file, everything happens in the tmp folder.
# /tmp/data
drwxrwxr-x 4 root www-data 4096 Apr 4 00:00 data
# /tmp/data/data.log
-rwxrwxr-x 1 root www-data 9551 Apr 4 04:19 sync.log
I tried to login as www-data user for testing the shell script, and it works fine via command line but it's not good with PHP exec as below:
exec('sh /var/www/sync.sh');
I tried to dump the data and I am sure that I can touch the .sh file.
Is there anyone have ideas about this issue?
Thanks.
I'm trying to build a sign-up workflow. On the first page someone enters a bunch of information, then submits the form. The processing script /var/www/html/command/old/perl.php needs to call a different script (/home/ec2-user/perl.php) which in turn calls a perl script.
From the command line I am able to run the /var/www/html/command/old/perl.php file (while logged in as ec2-user) without problem. When I try to run it by visiting the script in my browser, however, I get a blank screen.
Here are the permissions on the two perl.php files:
[root#ip-172-31-30-184 old]# ls -l /home/ec2-user/perl.php
-rwxr-xr-x 1 nginx nginx 672 Oct 23 18:21 /home/ec2-user/perl.php
and
[root#ip-172-31-30-184 old]# ls -l /var/www/html/command/old/perl.php
-rwxr-xr-x 1 nginx nginx 94 Oct 23 18:24 /var/www/html/command/old/perl.php
the perl script itself (though I don't think it matters if the PHP scripts are working) has the following:
[root#ip-172-31-30-184 old]# ls -l /home/ec2-user/dnsmeapi.pl
-rwxr-xr-x 1 nginx nginx 1605 Oct 23 02:02 /home/ec2-user/dnsmeapi.pl
What am I missing to make it work via the browser?
So this is my code for the raspberry pi to get a still shot from the raspicam and save it on a directory,
<?php
exec('raspistill -n -hf -o /var/www/img/image.jpg --timeout 1');
?>
I have given the ownership and the permission to read/write in that forlder using -R. so my ls -al in /var/www is this
drwxr-xr-x 3 www-data www-data 4096 Jun 19 08:05 .
drwxr-xr-x 12 root root 4096 Jun 19 05:54 ..
-rwxrwxrwx 1 www-data www-data 74 Jun 19 08:30 getImg
drwxrwxrwx 2 www-data www-data 4096 Jun 19 09:21 img
-rw-r--r-- 1 root root 70 Jun 19 10:07 index.php
getImg is the script i tried to run the script as a file like shell_exec('/bin/bash ./getImg'); that also doesn't work.
i have added /bash/bin and tried to run the script without using the script file too but that doesn't get the results.
How ever when i try to run the php file in the terminal, it creates the image as it normally should. So i figure this must be a permission issue, but what else should i do with the permissions? I have given all the rights to the directory.
EDIT
So I have found a workaround to this. since I don't know what the cause for the problem, i'd not mark this as an answer, but please vote it to appear at the top.
I now execute the script using the cgi scripts. I have created a shell script in the /usr/lib/cgi-bin/
#!/bin/bash
echo "Content-type:text/html\n"
sudo raspistill -vf -n -o /var/www/img/image.jpg --timeout 1200 --metering matrix
echo "Status: 204"
I saved this as capture and made this executable, did nothing with the permissions though.
sudo chmod +x capture
now when i open the link http://192.168.1.85/cgi-bin/capture the browser will still get me a 500 internal server error message. how ever, the image would still be created.
I would now need to get the 500 internal server error to be fixed.
[I'd add this as a comment but don't have enough points for it]
if you use the optional parameters $output and $return_var to capture the output and return value what do you get?
string exec ( string $command [, array &$output [, int &$return_var ]] )
does your command rely on environment variables that may be available when you run it as your user but not as www-data? (you can use the env command to check that)
does it still work if you run it via terminal after switching user to www-data?
When I try to shell_exec('/home/user/scripts/./script') I get the following error:
terminate called after throwing an instance of 'boost::filesystem3::filesystem_error'
what(): boost::filesystem::create_directory: Permission denied: "/.script"
Aborted (core dumped)
shell_exec('whoami') returns www-data on my web-facing php script.
The permissions to the directory and file are exactly the same:
-rwxrwxr-x 1 user123 group456 8246 Jun 25 06:10 script
drwxrwxr-x 7 user123 group456 4096 Jul 10 14:54 .
In fact I can shell_exec('touch /home/user/scripts/test') and it will create the file with no problem.
$ ls -l /home/user/scripts/test
-rw-r--r-- 1 www-data www-data 0 Jul 10 14:54 test123
This is how my groups are set up for each user:
$ groups user123
user123 : group456
$ groups www-data
www-data : group456
Why am I getting this error?
The script your running has a typo: it's trying to make the folder /.script in the root folder instead of ./script (relative path).
Are you trying to execute script at /home/user/scripts/./script then you should run as shell_exec('sh /home/user/scripts/script')
When you add ./ there on path its interpreted differently.
When you pass ./script - You are referring to filename script in current directory.
Also you are actually getting error from your c program which tells us your system is stopping apache to gain root privileges. You can audit2allow to let apache gain needed privileges.
I'm running as www-data and I'm trying to execute a shell script using shell_exec(/foobar/script/myscript.sh), but I'm getting the following error when the script attempts to write to a log file
cannot create /foobar/foo.log: Permission denied
However, I don't run into any problems if I try running the script directly from the terminal. ie
$ sudo su www-data
$ /foobar/script/myscript.sh
$
Any idea what could be going on here?
I should also add that I added www-data to the group mybar and that this is what's showing up when I list the directory
drwxrwxr-x 3 mybar mybar 4096 May 14 14:18 foobar # ls -l /
-rw-rw-r-- 1 mybar mybar 2824 May 15 09:57 foo.log # ls -l /foobar
I think there can be two options:
web-server and php-fpm are run under different users (by default that should not be). Try echo shell_exec('whoami');
You have added www-data to mybar after php-fpm process had been started so it still "doesn't know" that it is (then I think restart of fpm should help).
This works for me:
sudo chown www-data:www-data -R foobar/
The directory you are trying to create the file in must belong to whoever is executing the command.
You can type:
ls -la
to see who it belongs to.
You should see something like this:
drwxr-xr-x 8 jack jack 4096 Jul 22 11:36 application
When I am logged into my ubuntu machine I am logged in as jack#jack so I can create files in the following directory without issuing the sudo command:
drwxr-xr-x 8 jack jack 4096 Jul 22 11:36 application
because it is owned by the current user.
When you try running a script that is executed by visiting a webpage. www-data is the user that is executing the command so any directory or file that you are trying to create/modify/delete must be owned by www-data.