I've got the upload script which accepts the file and process it further.
Before file is processed its temporary upload path is given to clamav which will read the file outside of the PHP context and return whether there is virus inside or not.
This workflow has worked quite well until it stopped. I've debugged my script and even though file gets processed correctly on the PHP side, it doesn't exist in the tmp location given in $_FILES (during the script execution before script finishes).
$_FILES['datafile']['tmp_name'];
# This gives the location: /tmp/phpxbXzY0 correctly.
file_get_contents($_FILES['datafile']['tmp_name']);
# This returns the file content correctly.
However when I am logged in as sudo on the machine and type: cat /tmp/phpxbXzY0 there is no such file.
What's weird that it happened on all my PHP servers, but on local it all works fine and I can read the file contents with cat command.
I am running 7.2.10-0ubuntu0.18.04.1 on Ubuntu 18.04 on EC2, kernel: 4.15.0-1009-aws
Any ideas what might be the problem?
For some reason on my servers configuration of: /etc/systemd/system/multi-user.target.wants/apache2.service file was the default one.
By default it has: PrivateTmp=true while it should've been: PrivateTmp=false
That's the feature of systemd: https://serverfault.com/questions/786211/access-files-in-system-tmp-directory-when-using-privatetmp
The problem wasn't present on my local, since Apache2 isn't started by systemd therefore not restricting the /tmp path.
I need to check now why the file version has changed, since it was working fine enough. I suspect there must be unattended upgrade enabled, since I am not sure what else could cause it.
Related
I have installed xampp on my windows 8.1 and wanted to add PHP to environmental variables. Therefore, under path i added ;C:\xampp\php; in the end, like i have done some long time ago.
Now, when i try to run any php function in cmd, i get the windows message
"This app can't run on your PC.."
and a "Access is denied" in cmd.
If i remove php from the path variable, i still get the same error.
What i suspect could be a problem is that when trying to add the variable by typing SET PATH=%PATH% I accidentally clicked enter and therefore might have added an some weird value, although i have double checked and the whole line looks fine (no weird leftovers or something).
I had the same problem, I have tried a lot of things, but without success ... At the end of my efforts, I noticed that the size php.exe is 0KB , so I copy php.exe from my backup folder, where size is php.exe 75kB and php via cmd works
I also faced the same problem, when I'm using composer(Dependency Manager for PHP). Then I realised the problem was coming from php.exe.
The causes of the error message "Access denied" in php.exe and possible solutions:
Path variable may be not added, so make sure that your path variable is added properly.
The antivirus software may have blocked access to the php.exe file. Check your antivirus software's log and quarantine.
You don't have the permissions to run the php.exe. Change the permissions of the file.
The php.exe file may have been damaged. Reinstall the application.
Some malware can be added a php.exe file into windows or system32 directory. Since default path variable includes those directories, operating system will load that malware rather than original php.exe . So try by adding your PHP directory path to the top of the path variable.(this was the problem in my case)
Refer this link for more details on common php.exe errors.
This worked for me:
(My PHP installation lives in C:\PHP. Administrator has sufficient rights.)
Added C:\PHP to PATH variable
Removed the 0Kb php.exe file that lived in C:\Windows\System32
(I guess this file caused the windows refusal to execute)
In my local development environment, I have Apache and PHP installed on Windows 7. I'm calling 7-Zip from my PHP program with exec. I tried at first with
exec('7z a example.zip example.pdf');
but it didn't create the zip file. After checking the Apache error log, I found
'7z' is not recognized as an internal or external command, operable program or batch file.
After changing the exec to include the full path to 7-Zip.exe, it worked.
exec('"C:\\Program Files\\7-Zip\\7z" a example.zip example.pdf');
But C:\Program Files\7-Zip is included in my Windows system PATH. The same PHP code works from the command line without using the full path.
php -r "exec('7z a example.zip example.pdf');"
Why is it requiring the full path when I use it with Apache?
An important point which I neglected to include when I originally posted this question is that I am already able to use exec() to call other programs included in the Windows System PATH without referring to them by their full paths.
Another point which I did not mention originally because I did not realize its relevance was that 7-Zip had been added to the PATH only recently, and I had restarted the Apache service after adding it.
I've WAMP installed on windows 8 and after reading your question I decided to test a couple of things.
Running echo exec('whoami'); echoed:
nt authority\system
This confirms what #Barmar said, Apache isn't running under the same user as you, so, the PATH is different.
I decided to stop Apache and start it manually under the Administrator account.
Then I tried:
echo exec('whoami');
Which outputted:
computername\administrator
I assumed that now the exec would work with PATH and tried:
echo exec('adb'); //android adb tool is on my PATH
Surprisingly, despite the fact Apache was running with the same user as me, the PATH still didn't work. I've no idea why this is happening and if someone has a clue please comment below.
I managed to use the PATH (using the Administrator account) with the following code:
https://stackoverflow.com/users/171318/hek2mgl
$WshShell = new COM("WScript.Shell");
$oExec = $WshShell->Run("cmd /C 7z a example.zip example.pdf", 0); // 0 invisible / 1 visible
I didn't test the code below, but you can try setting the PATH under the Apache Service account (nt authority\system), and then use the command, i.e.:
echo exec('set PATH=%PATH%;C:/path/to/7z');
echo exec('7z a example.zip example.pdf');
I believe the path will still be valid between restarts.
Update:
this answer, may help you setting the PATH for the account nt authority\system.
The Local System user's personal environment variables are specified
at "HKEY_USERS.DEFAULT\Environment". The machine-wide environment
variables are specified at
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment". The former isn't really easily accessible from
anywhere except the registry, but the latter is accessible from the
"Environment Variables" dialog on the "Advanced" tab of the "System
Properties".
For future users, the correct way to set the Apache PATH is:
You can use setEnv in .htaccess or putenv in PHP code to set
$PATH
Credit goes to hek2mgl
I just figured out what was causing this problem. It was actually unrelated to my original assumption.
I remembered seeing PATH information in phpinfo(), so I looked at that. In the "Apache Environment" section it did show all of the PATH except the path to 7-Zip, which I had just added to the system PATH recently. So apparently it DOES seem to have access to that path, but it wasn't using the current version of it. Why not?
Normally I would think I had just forgotten to restart Apache after updating the path, but I'd restarted it repeatedly while trying to figure this out. But apparently restarting Apache does not refresh this value. I had to stop it and then start it. Then the 7-Zip path showed up in PATH in phpinfo, and I was able to change my program back to using plain 7z.
When I try to use Webception over wamp server on my windows 7,8 the below error appears for each tests
'php' is not recognized as an internal or external command,operable program or batch file
I have already installed php and the path is correct. Does it need more setup? How I can fix this issue ASAP?
This is because windows does not know where to find the php.exe file as it is not in a folder that is on your PATH environment variable.
However, when using WAMPServer it is a VERY BAD IDEA to add the path containing the php.exe to your PATH in the traditional way, because of course in WAMPServer it is possible to have many version of PHP available within one instance of WAMPServer.
The best solution in a WAMPServer environment is to create yourself a little command file that you can run from within a command windows that will add the php path you want to use for this specific project.
So create yourself a .cmd file and place THAT file in a folder that is already on your windows PATH environement variable.
So for example :-
File = phppath.cmd
PATH=%PATH%;c:\wamp\bin\php\php5.5.12
ECHO --------------------------------------------
php -v
ECHO --------------------------------------------
Of course you can make this as clever as you like and accept parameter specifying the php version you want to run, but untill you actually have more than one PHP version installed this is good enough.
I was also having a problem with webception on wamp failing to find php despite it being available on user and system path.
I found that wamp on windows by default does not provide environment variables to PHP.
I fixed this by editing php.ini (in apache/apache/bin/php.ini)
and ensuring that the following is set
variables_order = "EGPCS"
As at the current webception version 0.1.0 there is a bug to do with path generation that fails tests because the test file cannot be found. There is a solution for this at https://github.com/syntithenai/Webception/
I have run into a truly strange issue for which i have no explanation whatsoever.
After setting up OS X Yosemite and my local dev environment using XAMPP, i installed ImageMagick through MacPorts. All is well, it runs perfectly fine on the commandline.
However, when executed through Apache and called through PHP, i get no output from it whatsoever.
I have done extensive research and found a variety of approaches:
Setting the path environment variable in Apache (which i tried)
Using an absolute path to the executable (which i do)
Checking if exec() is listed as a disabled function (which it is not)
Checking if convert is even callable, as in executable (which it is)
I even went as far as copying the convert executable to the local project root directory and trying to exec('./convert'); but to no avail. I always receive absolutely no output from that call. Not even an error message. Needless to say, when i run the same thing through the Terminal, it works fine.
I also tried:
Calling exec('ls'); to see if anything comes up at all (yes it does, that works fine)
Calling exec('which convert');, where i get no result at all - the call returns nothing
Calling exec('which ls'); to double-check if the problem was with which - but which ls works fine and gives me /bin/ls as a response.
Providing chmod 0777 to the executable - to no avail
Regardless from what i try or do, convert remains entirely untouchable to PHP/Apache.
Can anyone tell me why that is and how to remedy it?
Checking the Apache error logs, i found the following message:
dyld: Library not loaded: /opt/local/lib/libfreetype.6.dylib
Referenced from: /opt/local/bin/convert
Reason: Incompatible library version: convert requires version 18.0.0 or later, but libfreetype.6.dylib provides version 15.0.0
Research showed that there is a common approach changing some environment path variable that applies to Apache and its subsidiary processes while running. However, since i did not want to fiddle around like that, i went for a somewhat more raw approach:
I opened a terminal and went to the very root directory of my system. There i ran:
find . -name "libfreetype.6.dylib"
This gave me all the libfreetype.6.dylib files that were available on my system. One of them was in the XAMPP lib directory, another one was in /usr/local/lib.
I backup up the file in the XAMPP directory and then copied the one from /usr/local/lib there.
I then tested convert again through Apache and was given another, quite similar error message relating to libexpat.1.dylib. For that i repeated the copying process as above. Afterwards, convert was executable through Apache and the problem was solved.
When you run scripts and programs via your web server, they are being run by a different user. In Macs this is usually _www. The convert application can't be found because the path to its executable file (probably /usr/local/bin) isn't included in the $PATH environment setting for this user.
The simplest solution is just to prefix the command with the path to convert, i.e., exec('/usr/local/bin/convert ... ');
My setup is as follows: Windows 7, XAMPP with Apache and PHP enabled I have a PHP script in which I call an external program to do run a conversion. This external program is an EXE file, which requires 3 attributes:
The source file
The destination file
Additional flags (conversion type etc)
When I use the command line tool built into XAMPP to execute my script, everything works fine. But when I use the exec() function in my PHP script, no output file is created. I'm pretty sure the conversion is actually happening (it takes about 5 seconds, about the same time it takes to run the PHP script).
I think it's a permissions thing, so I already moved the EXE file to the same folder as my PHP file and adjusted the permissions of the entire folder (I granted all permissions to all users). I also disabled the Windows UAC and tried to put the command in a BAT file. The file just is not created.
Any help or tips would be greatly appreciated!
My PHP code is as follows:
exec('c:\converter.exe c:\src.txt c:\dst.txt -f', $output);
print_r($output);
When I print out $output, the array turns out to be empty. When I put the exact same command in Command Prompt, the code works like a charm (no syntax errors). I use absolute paths as well.
Try to copy your executable file in same folder as your application.
try
exec("script.exe src.txt dst.txt", &$output);
echo $output;
also, do not forget to use escapeshellcmd() to add some security to your application.
Thank you very much for your input! As it turns out, it was Windows issue caused by the 'Interactive Services Detection' feature. Apache was running as a system service, which prevented calls to external programs (with a GUI). I disabled the run-as-service feature in XAMPP, which solved the problem. A more thorough explanation can be found here: http://php.net/manual/en/book.exec.php