I'm currently migrating my LAMP from my Windows Server to a VPS running Debian 6. Most everything is working, however, one of the PHP scripts was failing to write to its configured log file. I could not determine why, so I wrote a new, simple, contrived PHP script to test the problem.
<?php
ini_set('display_errors', 1);
error_reporting(E_ALL);
echo exec('whoami');
$log = fopen('/var/log/apache2/writetest/writetest.log', 'a');
if ($log != NULL)
{
fflush($log);
fclose($log);
$log = NULL;
}
?>
However, it fails with the result:
www-data Warning: fopen(/var/log/apache2/writetest/writetest.log): failed to open stream: Permission denied in /var/www/_admin/phpwritetest.php on line 5
While I would never do it normally, to help diagnose, I set /var/log/apache2/writetest/writetest.log to chmod 777.
Both the directory and the file are owned by www-data:www-data.
The file was created with touch.
I ran strace to verify which process was performing the open:
[pid 21931] lstat("/var/log/apache2/writetest/writetest.log", 0x7fff81677d30) = -1 EACCES (Permission denied)
[pid 21931] lstat("/var/log/apache2/writetest", 0x7fff81677b90) = -1 EACCES (Permission denied)
[pid 21931] open("/var/log/apache2/writetest/writetest.log", O_RDWR|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
I checked and pid 21931 was indeed one of the apache2 child processes running under www-data. As you can see, I also included echo exec('whoami'); in the script which confirmed the script was being run by www-data.
Other notes:
PHP is not running in safe mode
PHP open_basedir is not set
Version info: Apache/2.2.16 (Debian) PHP/5.3.3-7+squeeze3 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o
uname -a: 2.6.32-238.19.1.el5.028stab092.2 #1 SMP Thu Jul 21 19:23:22 MSD 2011 x86_64 GNU/Linux
This is on a VPS running under OpenVZ
ls -l (file): -rwxrwxrwx 1 www-data www-data 0 Sep 8 18:13 writetest.log
ls -l (directory): drwxr-xr-x 2 www-data www-data 4096 Sep 8 18:13 writetest
Apache2's parent process runs under root, and the child processes under www-data
selinux is not installed (thanks to Fabio for reminding me to mention this)
I have restarted apache many times and rebooted the server as well
Remember that in order to reach a file, ALL parent directories must be readable by www-data. You strace output seems to indicate that even accessing /var/log/apache2/writetest is failing. Make sure that www-data has permissions on the following directories:
/ (r-x)
/var (r-x)
/var/log (r-x)
/var/log/apache2 (r-x)
/var/log/apache2/writetest (rwx)
/var/log/apache2/writetest/writetest.log (rw-)
Does the php file doing the writing have proper permissions set? Try changing those to see if that's the issue.
Could be a SELinux issue, even if Debian doesn't ship it in the default installation your provider could have enabled it. Look for messages in /var/log with
grep -i selinux /var/log/{syslog,messages}
If that's the cause and you need to disable it, here are instructions: look for file /etc/selinux/config, here it's default content. Change SELINUX directive to disabled and reboot the system.
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
Related
I'm having permissions problems when running the following PHP script as root:
#!/usr/bin/php
<?php
$ph = proc_open('whoami', [['pipe','r'],['pipe','w'],['file','/tmp/foo.bar', 'w']], $fds);
if ($ph) {
echo 'command output: ' . stream_get_contents($fds[1]);
proc_close($ph);
} else {
echo 'proc_open failed' . PHP_EOL;
}
The script itself runs fine if /tmp/foo.bar doesn't exist, or is owned by root. But if ownership is changed to another user, proc_open will fail regardless of permissions on the file.
SELinux is disabled, and we are not using ACLs. I'm using PHP 7.4.33 (I know it's old and unsupported, but it's a requirement for FreePBX) on Alma Linux 9.1.
Output:
$ ./test.php
command output: root
$ ls -lah /tmp/
total 12K
drwxrwxrwt. 18 root root 4.0K Dec 14 16:57 .
dr-xr-xr-x. 18 root root 4.0K Dec 14 16:48 ..
-rw-r--r-- 1 root root 0 Dec 14 16:57 foo.bar
$ chown admin /tmp/foo.bar
$ ./test.php
proc_open failed
$ chmod 777 /tmp/foo.bar
$ ./test.php
proc_open failed
$ ls -lah /tmp/
total 12K
drwxrwxrwt. 18 root root 4.0K Dec 14 16:57 .
dr-xr-xr-x. 18 root root 4.0K Dec 14 16:48 ..
-rwxrwxrwx 1 admin root 0 Dec 14 16:57 foo.bar
$ tail -2 /var/log/php.log
[14-Dec-2022 16:57:17 America/Toronto] PHP Warning: proc_open(/tmp/foo.bar): failed to open stream: Permission denied in /test.php on line 3
[14-Dec-2022 16:57:28 America/Toronto] PHP Warning: proc_open(/tmp/foo.bar): failed to open stream: Permission denied in /test.php on line 3
Even disregarding the fact that I'm root, group permissions should allow me full access to the file. So what's going on?
This is due to the permissions on the /tmp directory. When PHP tries to open the file for writing, it gets the EACCES error. From the documentation of open(2):
EACCES
Where O_CREAT is specified, the protected_fifos or protected_regular sysctl is enabled, the file already exists and is a FIFO or regular file, the owner of the file is neither the current user nor the owner of the containing directory, and the containing directory is both world- or group-writable and sticky. For details, see the descriptions of /proc/sys/fs/protected_fifos and /proc/sys/fs/protected_regular in proc(5).
/tmp has the sticky bit set so that anyone can create files there, but users can only delete their own files. Although root can bypass this deletion restriction, it can't bypass the above check in open().
Ok I tried this in a different directory than /tmp, as suggested in comments, and it worked as expected. Using that to hone my search terms I was able pretty quickly to find this U&L answer. Beginning with kernel 4.19 the fs.protected_regular kernel parameter was made available. This parameter:
Disallows open of FIFOs or regular files not owned by the user in world writable sticky directories, unless the owner is the same as that of the directory or the file is opened without the O_CREAT flag. The purpose is to make data spoofing attacks harder.
Apparently it's enabled by default. So because /tmp is world-writable and sticky, I can't touch files that aren't mine – even if I'm root. For the record, if I have to disable this feature:
sysctl fs.protected_regular=0
echo 'fs.protected_regular=0' > /etc/sysctl.d/90-writabletemp.conf
But I'll be better off trying to work around it in the code somehow.
I edited the apache httpd.conf file recently for the mod_rewrite to work. I don't know if this problem originated from that or not, but i'm getting this problem from that day.
This is what I see on the frontend when I run the software -
Server error The website encountered
an error while retrieving
http://localhost/prestashop/. It may
be down for maintenance or configured
incorrectly.
There is no specific file that triggers this. But I saw that usually small programs that consists of 4-5 php files, runs fine, but softwares with a lot of files(like PrestaShop) don't.
I checked the logs and this is what I found.
[Wed Mar 16 19:33:39 2011] [error] [client ::1] PHP Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
[Wed Mar 16 19:33:39 2011] [error] [client ::1] PHP Fatal error: Unknown: Failed opening required '/var/www/html/yomig/index.php' (include_path='.:/usr/share/pear:/usr/share/php') in Unknown on line 0
[Wed Mar 16 19:33:39 2011] [error] [client ::1] File does not exist: /var/www/html/favicon.ico
[Wed Mar 16 19:33:41 2011] [error] [client ::1] PHP Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
[Wed Mar 16 19:33:41 2011] [error] [client ::1] PHP Fatal error: Unknown: Failed opening required '/var/www/html/yomig/index.php' (include_path='.:/usr/share/pear:/usr/share/php') in Unknown on line 0
Experienced the same error, for me it was caused because on my Mac I have changed the DocumentRoot to my users Sites directory.
To fix it, I ran the recursive command to ensure that the Apache service has read permissions.
sudo chmod -R 755 ~/Sites
If you are running Fedora, make sure SELinux is not interfering.You fix this with this command:
sudo /sbin/restorecon -R /var/www/
More info here: linuxquestions.org/questions/linux-server-73/
I had the same error and my problem was the file permissions were incorrect.
chmod 755 index.php
worked for me.
It is a SELinux blocking issue, Linux prevented httpd access. Here is the solution:
# restorecon '/var/www/html/wiki/index.php'
# restorecon -R '/var/www/html/wiki/index.php'
# /sbin/restorecon '/var/www/html/wiki/index.php'
Here some guide how to fix it. Go to :
cd /var/www
sudo chown www-data:www-data * -R
sudo usermod -a -G www-data username
Change userneme with your username. I hope it help.
I got this problem when insert wrong file address into .htaccess
php_value auto_prepend_file "/home/user/wrong/address/config.php"
So if you use auto_prepend_file check your file path. It called from .htaccess so PHP can't determine error file and line.
In my mind true way is:
# add READ permission to all directories and files under your DocumentRoot
sudo chmod +r /path/to/DocumentRoot/ -R
# add EXECUTE permission to all DIRECTORIES under your DocumentRoot
find /path/to/DocumentRoot/ -type d -exec chmod +x {} \;
I just came across of this same problem and in my case it was caused by selinux. Disabling it solved the issue. And no, I don't need selinux on my workstation, thank you.
It happened to me today with /home/user/public_html/index.php and the solution was to do chmod o+x /home/user as this directory has to have the X as otherwise the apache server can't list files (i.e. do ls)
This also happens (and is particularly confounding) if you forgot that you created a Windows symlink to a different directory, and that other directory doesn't have appropriate permissions.
Just quote for above answer of user1992554
This one worked perfectly for me in Linux Mint, to get rid of Warning: failed to open stream: Permission denied
cd /var/www
sudo chown www-data:www-data * -R
sudo usermod -a -G www-data username
In Fedora 25, it turned out to be an SE Linux issue, and the notification gave this solution which worked for me.
setsebool -P httpd_read_user_content 1
In my case the group _www that apache uses was missing in the folder's access list, so first I had to add the missing group, like so:
sudo chown -R _www ~/path-to-folder
Change _www to whatever user or group that apache is running as.
Find out apache's user/group using apachectl -S
The output is huge, but look at the very end something like:
User: name="_www"
Group: name="_www"
This isn't a direct answer to the question, but I had the same problem. I installed VSFTPD on my Ubuntu Server VPS. I could upload files, but every file I uploaded didn't have execution permissions (all files had rights "600"). These posts explain explain exactly what you have to do to configure your VSFTPD to set default rights on your files:
Default File Permissions Apache /var/www/
vsFTPd default uploaded file permissions on Ubuntu not working
Once, this happens to me as well. and when I googled the matter, I got to know that this happens when the permissions on the file is wrongfully set to 000 (which means that no one can read, write, or execute that file). Then I just changed my file permission privilege into Read & Write and it's worked for me.
To change file permission settings on mac: Right click on the particular file and click on Get info from dropdown menu and refer to the sharing and permissions panel and change privilege settings into Read & Write
More: http://www.itoctopus.com/warning-unknown-failed-to-open-stream-permission-denied-in-unknown-on-line-0-error-in-joomla
Check dos and unix file format. This problem is seen on linux platforms if dos file format is used. Use doc2unix command like below and then retry it should work
dos2unix *.php
This solution for below problem
Wed Nov 12 07:50:19 2014] [error] [client IP1] PHP Warning: Unknown: failed to
open stream: Permission denied in Unknown on line 0
[Wed Nov 12 07:50:19 2014] [error] [client IP1] PHP Fatal error: Unknown: Failed
opening required '/var/www/html/index.php' (include_path='.:/usr/share/pear:
/usr/share/php') in Unknown on line 0
Go to folder htdocs
cd htdocs
Execute
chmod -R 755 sites
No need to sudo !
Except the permissions, the problem can be open_basedir. If you are using it (and I suggest to use it) then check the settings at the VirtualHost :
php_admin_value open_basedir <YOUR ROOT>
Im developing simple (dead simple) front end for openwrt using PHP. To do this I need to call many openwrt UCI (Unified conf. interface) commands through PHP shell_exec() or system() functions. All the UCI commands that I tried in terminal are working perfectly fine. But as soon as I run them through above functions they are simply not working.
As an example I run following two commands which worked well in terminal
uci set wireless.#wifi-iface[0].ssid=test
uci commit
But as soon as I run them through PHP nothing happens. They are simply not working. The I make .sh file and save above two lines and run that files using PHP but again!! results are the same. But when I execute .sh file through terminal it works!!
For testing I set the both file permission to 777. but that doesn't helps. Is there are any additional requirements to run shell commands through PHP like root access to the PHP or Apache ? I'm new to this and I would thankful if someone can help
my apache error_log
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117] uci
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117] :
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117] I/O error
[Wed Aug 19 08:26:53 2015] [error] [client 192.168.2.117]
Im using apache as a web server and openwrt Chaos Calmer 15.05-rc3 as my base firmware on top of Raspberry pi 2
I managed to solve my problem using uhttpd web server instead of Apache. Apache somehow doesn't have enough privileges to execute UCI commands directly. uhttpd the default web server in openwrt can execute this commands directly
I tried to figure out the same problem and my conclusion so far is run php with root permissions. I know this is not secure, but at least it works. Here is one line from /etc/init.d/php5-fpm to run php-fpm with root privileges:
service_start $PROG -R -y $CONFIG -g $SERVICE_PID_FILE
The key flag here:
-R, --allow-to-run-as-root Allow pool to run as root (disabled by default)
Both answers are right. What sameera mentions was the fact that uhttpd has special rights running on LEDE or OPENWRT (as default), but what Anton Glukhov wrote is also correct, it allowed me to run as root but limited to avoid errors. I was not able to run my scripts (.sh) as with uhttpd, but php runs ok and does not have any bugs while running as root. I guess its a file permissions issue by default on Nginx with Openwrt. My solution was leave uhttpd running on a different port and run my program with all the rights and permissions while running everything else as non root in Nginx. Security is no issue in my case, its offline server.
service_start $PROG -R -y $CONFIG -g $SERVICE_PID_FILE
Works, in my case editing adding the -R flag in /etc/init.d/php7-fpm
I'm kinda novice on setting up a PHP environment (Apache), but nothing to do about it.
I have a VPS, which has Ubuntu 12.04 LTS.
My issue is that I receive following error:
[Wed Nov 13 16:43:31 2013] [error] [client 127.0.0.1] PHP Fatal error:
Unknown: Failed opening required '/root/blog/index.php'
(include_path='.:/usr/share/php:/usr/share/pear') in Unknown on line 0
index.php contains following code:
<?php
print phpinfo();
?>
It is WORKING IF it is located under "/var/www/" directory.
But I wanted to change the location of the script to "/root/blog".
I have re-configured the "000-default" configuration file under "sites-enabled" folder in apache2 folder. So it shouldn't be a problem.
I've tried assigning different permissions (chmod 777) to "/root/blog" folder (both: recursively and traditionally), but no avail.
I've checked the user and user group for the "/var/www" folder and files, and they are:
root/root - root user and root group. So, that should not be an issue.
What should I do about it ?
Can someone help me ?
P.S AFAIK, apache version: 2.2, PHP: 5.3.10 (installed today, using apt-get install php5 apache2)
I imagine the problem comes from the Apache user not having permission to read/execute files under the /root directory, since after all, that's the root user's home directory.
I really recommend you don't serve your website from /root but if you really want to try executing this command:
chown -R nobody /root/blog
(I'm assuming nobody is your Apache's user)
Out of curiosity, why run the website from /root? /var/www is the standard location for website files and if it works when the files are under this directory why not stick to it?
I have a previously working PHP script that is able to create a directory with mkdir:
$webfolder = "/var/www/html/images/user";
mkdir($webfolder, 0770);
I made some changes to the permission setting of the folder /var/www/html/images which is now:
drwxrwx---. myself apache system_u:object_r:httpd_sys_content_t:s0 images
I think previously this folder was owned by apache. But since apache has the full privileges of read, write and execute as a user group, I wonder why it can't create a folder within. Using the mkdir produces a false boolean value.
Is the problem due to directory ownership or is there some other reasons? Note that I am using PHP version 5.4.
Error Log added:
[Mon Dec 17 11:12:34 2012] [error] [client 127.0.0.1] PHP Warning:
mkdir(): Permission denied in /var/www/html/upload on line 33,
referer: https://mywebsite.com/referer
The answer is staring right in front of me, but I miss it due to my unfamiliarity with SELinux.
The SELinux context type should be set as httpd_sys_content_rw_t instead of httpd_sys_content_t so that the folder is both readable and writable for apache. Changing the context recursively is done with the following command:
# chcon -R -t httpd_sys_content_rw_t /var/www/html/images
Good grief. Hope it helps others who come across this.
On CentOS7 VM, with PHP5.4.16/Apache 2.4.6/mariadb 5.5.44, the smarty template directory was not writable to generate compiled templates files and was giving the below error (in /var/log/httpd/error_log):
[Thu Mar 31 12:36:08.201383 2016] [:error] [pid 13094] [client 192.168.212.65:52204] PHP Fatal error: Smarty error: unable to write to $compile_dir '/var/www/html/app1/templates_c'. Be sure $compile_dir is writable by the web server user. in /var/www/html/app1/libs/smarty/Smarty.class.php on line 1093
hence the PHP application was displaying blank screen.
chmod 777 templates_c did not work either; but as per the suggestion by #Question Overflow, permission on web root on this VM did solve the problem.
I had to execute:
[root#appserver html]# chcon -R -t httpd_sys_content_rw_t /var/www/html
of course, the templates_c & cache should be owned by apache user:
drwxr-xr-x. 2 apache apache 6 Mar 31 12:56 templates_c
drwxr-xr-x. 2 apache apache 6 Mar 31 12:56 cache
After spending more than half a day, came across this.
Thanks