I am running Drupal 8 on a vps running latest ispconfig/apache fastCGI.

Security review module reports: "Some files and directories in your install are writable by the server." and basically lists all my files.

Now all files are set with the correct permissions: 644 for files, 755 for directories.

I suspect the problem is file ownership. Ispconfig creates a new user for each site and they belong to a client group.

So for this site all files belong to: web65:client0

which means: owner is web65 and group is client0

And I noticed the www-data user is a part of the client0 group.
Apache is of course running as www-data.

Is this the problem? That the webserver is a member of the client group?
And what would be the best fix? I suspect this is a problem for all ispconfig users?

Any ideas?

Comments

robotjox created an issue. See original summary.

genfoch01’s picture

genfoch01 commented

not sure if this will help, but based on the drupal security configuration i was able to find ( https://www.drupal.org/node/244924 )

permissions should be 640 for files and 750 for directories unless you have a files directory which you web server would need to have write access to.

from what you have described, the files are owned by web65 with group client0 while the web server runs as "www-data"
that being the case even with a 644 file permission web server would not have write access to the files even if www-data is included in the client0 group.

have you verified apache really is running as www-data? the other possibility is an ACL overriding the basic unix perms (assuming you are using linux )

hope that helps

robotjox’s picture

robotjox commented

thanks for your suggestions.

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)

If I do a getfacl on one of the files I get:

# file: 2699477-66_0.patch
# owner: web65
# group: client0
user::rw-
group::r--
other::---

Any ideas on how to troubleshoot this further?
Thanks!

genfoch01’s picture

genfoch01 commented

if you could switch users to www-data you would be able to check if those files are in-fact writable. if www-data can't write to the files, then it would eliminate your server from the equation.

robotjox’s picture

robotjox commented

Thanks for replying so fast!
I tried

sudo -u www-data touch test.txt

in the root of the webfolder and I get a permission denied.

So I guess that means www-data has no write permissions!

I'm really baffled now...

genfoch01’s picture

genfoch01 commented

try sudo su - www-data
then see if you can edit one of the files

I have seen sudo -U not pick up all a users environment

genfoch01’s picture

genfoch01 commented

so i just ran into this exact issue on a hosted site. turns out the php handler is running as my id so it can write to my drupal folders while apache is running as "nobody". thus technically the web server does have write access.

i am in contact with my hosting site about this not sure its going to help, may just have to live with it.
i will post back with results.

UPDATE: for the hosting site, apache hands the incoming data off to the php handler which is running under my id. the only way to pass the security review i guess would be to set all files to read only for owner

update 2 : as a test i looked at one of the files security review said was writable (./sites/readme.txt ) and did chmod 444 on it and it is no longer listed in the report. i'm fairly confident the issue is with the hosting company (in my case anyway) though i'm not sure if there is anything i can do about it.

robotjox’s picture

robotjox commented

As I suspected this setup is "by design" in ispconfig.

I got a really good and lengthy reply on the ispconfig forum by the software maintainer, which can be read here: https://www.howtoforge.com/community/threads/file-ownership-permission-p...

As far as I can understand his reply there are pros and cons in giving apache (or rather PHP?) write permissions.

I am still a bit confused in how to approach this problem, and which approach is the one to follow here :-) :-)

genfoch01’s picture

genfoch01 commented

funny you should ask about which approach to use, i was going to post a comment on the security discussion page (https://www.drupal.org/node/244924) but it looks like comments are disabled.

My understanding from the drupal page is like yours apache should not be able to update drupal files on your site.
in your case and mine, if apache forwards the data to php which is running as the drupal owner id you can technically say apache does not have write access to your files, but i think the intent of the recommendations in the drupal article is that you should not be able to alter drupal code vi the web UI at all. ( this is my takeaway and i could be wrong )

this is to prevent files being altered thus compromising the site. it does however present a question. if apache/php can't update files, then the reports/updates page will no longer be able to update modules (which i think is what your hosting site was getting at)

I have one server in house where php runs under the apache id and i get around this issue by changing ownership of the drupal files to the apache id, updating the modules i need and changing the ownership back. (I'm not real happy with this solution but it will work until i figure something better out)

on my hosting site, this is not an option as i don't have chown rights. I'm not yet sure how i'm going to address this issue with them.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)

Wonder if this is still an issue? If so could we get an updated issue summary

genfoch01’s picture

genfoch01 commented

It is still a problem for me. on my hosted site, security review reports all files writable by server.
in my Drupal installation I set all directories to 755 and all files to 644. I am the owner and group for all files and directories.
these settings I got from https://www.drupal.org/node/244924

the host runs the web server runs as www-data and that's its group as well.

On my hosting site, there is a php process that is handed requests by the apache server. The php process runs as my id. So apache can't really write to the files, but the php process which is handed the request from apache does have write access to all the files.

so Technically apache can't write to the Drupal files, but the php handler can so this affectively bypasses permission settings see above for settings)

which is why (i think ) security review flags all files as writable. I have a feeling most hosting sites are set up this way. I don't really think this is a Drupal issue but I think everyone show know about it and those using a hosting site might want to look as it is a really security hole

smustgrave’s picture

smustgrave commented

Can you confirm if it’s a Drupal issue? If not I think it would be worth adding the README though for others

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

The scenario described in #11 is a security risk and something the module is intentionally warning about as potentially lproblematic.

genfoch01’s picture

genfoch01 commented

I agree it is a security risk and should be reported by security review. I also think this is a common issue for hosted Drupal sites. I have not seen a formal Drupal security best practice ( there may be one but I have not found it ) just the locked discussion I posted in #11. so there is nothing I can bring back to my hosting company and say your doing it wrong and need to change.

smustgrave’s picture

smustgrave commented
Version: 8.x-1.x-dev » 2.0.x-dev
smustgrave’s picture

smustgrave commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

closing out as works as designed as we seem to be in agreement that the module is correctly working.

If we feel like it could be worth starting a scenarios section in the README then we can reopen.