PHP is_writable() function always returns false for a writable directory

Question

I'm trying to install a PHP-based software package in a Red Hat 7 Amazon EC2 instance (ami-8cff51fb) that has had Apache 2.4.6 and PHP 5.4.16 installed on it using yum. The installation fails because it says a particular directory needs to be writable by the webserver with 0755 or 0775 permissions.

The directory in question has 0775 permissions with root:apache ownership. I have verified that the httpd process is being run by the apache user and that the apache user is a member of the apache group.

If I edit /etc/passwd to temporarily give the apache user a login shell and then su to that account, I am able to manually create files as the apache user within the directory using the touch command.

I took a look at the source code of the installer script and identified that it's failing because PHP's is_writable() function is returning false for the directory in question. I created a separate test PHP script to isolate and verify the behaviour I'm seeing:

<?php
  $dir = '/var/www/html/limesurvey/tmp';
  if (is_writable($dir)) {
    echo $dir, ' is writable';
  } else {
    echo $dir, ' is NOT writable';
  }
?>

This outputs the NOT writable message. If I change $dir above to be /tmp then it correctly outputs that /tmp is writable.

If I change the directory permissions to 0777 and/or change the ownership to apache:apache then PHP still reports that the directory isn't writable. I even tried creating a /test directory set up with the same permissions and ownership and my test script still reports it as not writable.

I'm really at a loss as to explain this behaviour, so any ideas would be welcome!

Thanks in advance.

---

The directory listing for /var/www/html/limesurvey is given below. The tmp and upload directories have 0775 permissions as per Lime Survey's installation instructions. test.php is my test script mentioned above.

[ec2-user@ip-xx-x-x-xxx limesurvey]$ pwd
/var/www/html/limesurvey
[ec2-user@ip-xx-x-x-xxx limesurvey]$ ls -al
total 80
drwxr-xr-x. 20 root apache 4096 Mar 30 11:25 .
drwxr-xr-x.  3 root root     23 Mar 25 14:41 ..
drwxr-xr-x.  2 root apache   38 Mar 10 12:56 admin
drwxr-xr-x. 16 root apache 4096 Mar 10 12:56 application
drwxr-xr-x.  3 root apache 4096 Mar 10 12:56 docs
drwxr-xr-x.  2 root apache 4096 Mar 10 12:56 fonts
drwxr-xr-x. 19 root apache 4096 Mar 10 12:56 framework
-rw-r--r--.  1 root apache  429 Mar 10 12:56 .gitattributes
-rw-r--r--.  1 root apache  399 Mar 10 12:56 .gitignore
-rw-r--r--.  1 root apache  296 Mar 10 12:56 .htaccess
drwxr-xr-x.  4 root apache 4096 Mar 10 12:56 images
-rw-r--r--.  1 root apache 6652 Mar 10 12:56 index.php
drwxr-xr-x.  5 root apache   39 Mar 10 12:56 installer
drwxr-xr-x. 89 root apache 4096 Mar 10 12:56 locale
drwxrwxr-x.  2 root apache   39 Mar 25 14:41 logs
drwxr-xr-x.  4 root apache   49 Mar 10 12:56 plugins
-rw-r--r--.  1 root apache   61 Mar 10 12:56 README
drwxr-xr-x.  4 root apache 4096 Mar 10 12:56 scripts
-rw-r--r--.  1 root apache  380 Mar 10 12:56 .scrutinizer.yml
drwxr-xr-x.  5 root apache 4096 Mar 10 12:56 styles
drwxr-xr-x.  5 root apache 4096 Mar 10 12:56 styles-public
drwxr-xr-x. 12 root apache 4096 Mar 10 12:56 templates
-rw-r--r--.  1 root apache  159 Mar 30 11:11 test.php
drwxr-xr-x.  3 root apache   20 Mar 10 12:56 themes
drwxr-xr-x. 26 root apache 4096 Mar 10 12:56 third_party
drwxrwxr-x.  5 root apache   80 Mar 26 13:45 tmp
drwxrwxr-x.  6 root apache   79 Mar 10 12:57 upload

Running namei -l /var/www/html/limesurvey/tmp gives:

[ec2-user@ip-x-x-x-xxx ~]$ namei -l /var/www/html/limesurvey/tmp
f: /var/www/html/limesurvey/tmp
drwxr-xr-x root root   /
drwxr-xr-x root root   var
drwxr-xr-x root root   www
drwxr-xr-x root root   html
drwxr-xr-x root apache limesurvey
drwxrwxr-x root apache tmp

Solution 1

After much head-scratching, it transpired that SELinux was preventing the directory from being written to. I found a good tutorial that explains what's going on. I was able to fix it by running this command:

sudo chcon -R -t httpd_sys_rw_content_t tmp

Solution 2

in CentOS 6 above should be SELinux enable enforcing

setenforce Permissive

check the status

sestatus

refer to https://wiki.centos.org/HowTos/SELinux

Comments

[John Topley]

I've edited the question to include the namei output. As you can see, the entire directory tree has owner and group execute permissions.

[John Topley]

Thanks, but it didn't work. According to the docs, that option was removed in PHP 5.4.0. I'm using PHP 5.4.16.