File ownership/permission problem with Drupal 8

Discussion in 'ISPConfig 3 Priority Support' started by robotjox, Apr 21, 2020.

  1. robotjox

    robotjox New Member

    when I run a security audit on my Drupal installation running on Ispconfig 3.1.15p2 I get the following warning that all my "files and directories in your install are writable by the server."

    Now all files are set with the correct permissions: 644 for files, 755 for directories.
    And all files belong to the client: web65:client0

    ps aux | egrep '(apache|httpd)' gives me:

    www-data   628  0.0  0.0  19632   140 ?        Ss   Jan06   7:15 /usr/bin/htcacheclean -d 120 -p /var/cache/apache2/mod_cache_disk -l 300M -n
    root     12117  0.2  0.0 594372  1308 ?        Ss   14:31   0:07 /usr/sbin/apache2 -k start
    www-data 12123  0.0  0.0 185188   672 ?        S    14:31   0:01 /usr/sbin/apache2 -k start
    www-data 15378  0.0  0.0 594776  6252 ?        S    15:10   0:00 /usr/sbin/apache2 -k start
    www-data 15379  0.0  0.1 594760  6476 ?        S    15:10   0:00 /usr/sbin/apache2 -k start
    www-data 15640  0.0  0.0 594776  6164 ?        S    15:16   0:00 /usr/sbin/apache2 -k start
    www-data 15661  0.0  0.0 594736  6036 ?        S    15:16   0:00 /usr/sbin/apache2 -k start
    www-data 15901  0.0  0.0 594800  6176 ?        S    15:20   0:00 /usr/sbin/apache2 -k start
    www-data 15902  0.0  0.0 594632  5828 ?        S    15:20   0:00 /usr/sbin/apache2 -k start
    www-data 16299  0.0  0.0 594584  5264 ?        S    15:29   0:00 /usr/sbin/apache2 -k start
    www-data 16312  0.0  0.0 594592  5136 ?        S    15:29   0:00 /usr/sbin/apache2 -k start
    www-data 16313  0.0  0.0 594992  4748 ?        S    15:29   0:00 /usr/sbin/apache2 -k start
    www-data 16316  0.0  0.1 596680  7348 ?        S    15:29   0:00 /usr/sbin/apache2 -k start
    www-data 16317  0.0  0.0 594476  3976 ?        S    15:29   0:00 /usr/sbin/apache2 -k start
    root     16476  0.0  0.0  15528  1172 pts/1    S+   15:31   0:00 grep -E --color=auto (apache|httpd)
    Any ideas?
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    There is no issue or problem with your setup. The files are owned by the right user and have the right permissions. It is intended that the files are owned by the user that runs the website PHP process to allow online updates and also to upload themes, images or other media files as one might want to do when using a cms. If you don't want that PHP is able to write these files, then disable the suexec checkbox in the website settings, in this case PHP will run as www-data user and group instead of running as website user and client group of the site.

    Btw. The ps command you posted can not give you any insight on this.
  3. robotjox

    robotjox New Member

    Thanks a lot for answering, till.
    I was under the impression that the ps command would show me which user apache was running as. states:
    "The server file system should be configured so that the web server (e.g. Apache) does not have permission to edit or write the files which it then executes. That is, all of your files should be 'read only' for the Apache process, and owned with write permissions by a separate user."
    Do you disagree and what are the drawbacks in disabling suexec?

    thanks again!
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    That's correct. But PHP these days does not run as apache module anymore, so the user that Apache runs under is not necessarily the user that PHP runs under and what Drupal refers to is the user which executes Drupal files, so they refer to the PHP process.

    One can do such a setup. But as most CMS systems provide the ability to do online updates, such a setup prevents easy updates. This, in the end, causes users sooner or later to not install updates anymore because it's inconvenient and installing no updates is worse than having write privileges in the site in my opinion. But that#s just spoken from what I've experienced with many clients. So yes, you can disable suexec, but you'll have to make at least all folders where media files are stored writable for the www-data user. This way, you protect the drupal sourcecode files from being altered by the PHP process, but by making your media folder writable for the www-data user, you open up the potential ability that other sites put files in there if the server runs multiple sites. And a hacker would be able to upload and execute his code in the media folder as well of course, so doing what Drupal suggests may prevent modifications only partially and comes with drawbacks and introduces other security issues. And things like theme uploads or plugin installations trough the Drupal UI, if Drupal offers such an option, won't work as well anymore.
  5. robotjox

    robotjox New Member

    Thanks a lot for your thorough reply!

Share This Page