Hello, 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: Code: 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? Thanks!
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.
Thanks a lot for answering, till. I was under the impression that the ps command would show me which user apache was running as. Drupal.org 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!
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.
