Hi... I'm having trouble with some files in the "Status report" in "Reports" link at the back end...

In the configuration section I got this message

Not protected
Protection disabled
The file sites/default/settings.php is not protected from modifications and poses a security risk. You must change the file's permissions to be non-writable.
The file sites/default/settings.local.php is not protected from modifications and poses a security risk. You must change the file's permissions to be non-writable.

I tried to fix it doing:

chmod 644 sites/default/settings.local.php
chmod 644 sites/default/settings.php

I also tried :
chmod 755 sites/default

But files belongs to the group www-data and his owner is my user (victorarango) which is not a member of www-data

But I still recieve the same message...

I'm using Ubuntu 16.04 with PHP Version 5.6.26-2+deb.sury.org~trusty+1

Comments

onejam’s picture

chmod 444 /sites/default/settings.php

That makes your settings.php file read only which is what is required to protect the file.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

vihuarar’s picture

Hi...

Thank you very much.. very quick answer... but...
I already tried to do that... chmod 444 sites/default/settings.php but still got the same message...
Note: you made a mistake... is chmod 444 sites/default/settings.php instead chmod 444 sites/default/settings.php

This is the screenshot of the ssh terminal of the actual permissions..
http://i63.tinypic.com/33m8uwo.jpg

I also tried... chattr +i sites/default/settings.php

onejam’s picture

Also, make sure your default directory is chmod 555

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

vihuarar’s picture

Still the same... check the permissions here:
http://es.tinypic.com/r/11t7n6p/9

I did chmod 555 default

onejam’s picture

Yep, that all looks fine so i'm not sure why it's not showing up as protected. Maybe refresh the report page or clear the cache?

That is the same file and directory permission settings i have and it's ok.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

vihuarar’s picture

I made a drush cache cr but still the same...

do you think that this is a bug that I should report?

onejam’s picture

No, it's not a bug.

Are you sure you are working on the same installation? Everything looks ok to me so do not know why it's still showing up as unprotected?

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

vihuarar’s picture

Yep.. is the same installation...
Let's wait some time... maybe somebody else give us a clue...

Thanks @duvien

HenryHartley’s picture

I've got the same thing going on here. I've even tried setting the permissions to 004 and that didn't work. I thought perhaps SELinux context was part of the problem but I have the file set to httpd_sys_content_t (same as update.php in the site's root and it doesn't complain about permissions there).

This is RHEL 7, PHP 7.0.12, Drupal 8.2.1

Anonymous’s picture

First of all the Drupal documentation states the following:
Permission on sites/default should be 755 [drwxr-xr-x]:
Permission on settings.php should be 644 [-rw-r--r--]:

I'm using Drupal 8.2 and I'm getting the message even when permissions are as described above. This is clearly a bug.

vihuarar’s picture

onejam’s picture

@pferlito - Your permissions are wrong. In step 5 of the docs, it says:

555 (read-execute) [dr-xr-xr-x] for the sites/default folder.
and
444 (read-only) [-r--r--r--] for the settings.php

@vihuarar, perhaps you need to add your user to group www-data on Ubuntu? Have a look here for more details: http://drupal.stackexchange.com/questions/373/what-are-the-recommended-d... It should still apply for Drupal 8 (even though the directories structure has changed from D7).

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

Anonymous’s picture

@duvien please post a link to the doc you are talking about and no, SO is not official Drupal doc.
In the meantime I'll post another official Drupal documentation link: http://cgit.drupalcode.org/drupal/tree/core/INSTALL.txt

In 3c it says:
Sample commands
from a Unix/Linux command line:

chmod go-w sites/default/settings.php
chmod go-w sites/default

Note that user write permissions are NOT removed by the above commands.
Also note that execute permissions are not removed for anyone.

And none of this matters because we both tried it your way with the same result.

onejam’s picture

The link to the doc is the one you posted up in your own comment: https://www.drupal.org/docs/7/installing-drupal-7/step-3-create-settings... (see step 5)

The link i posted was for @vihuarar

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

Anonymous’s picture

Yes, I tried it that way also without success. That's when I found INSTALL.TXT. This is happening on one of my sites and not the others. I'm trying to ascertain what is different about it now.

RaisinBranCrunch’s picture

Are you perhaps using the `$settings['skip_permissions_hardening'] = TRUE;` option in either settings.php or settings.local.php ?

This option is in the `example.settings.local.php` by default, so it can surprise some people if they followed the guide on disabling cache locally, or if they use a settings.local.php that was originally copied from this.

HenryHartley’s picture

When I commented out that line in settings.php, the status report began correctly showing that the file is protected. So, yes, I missed that and yes, that seems to have been the problem (at least for me). It does seem like this might qualify as a bug, although perhaps a minor one, because the report should still not be reporting the file as vulnerable when it was not.

Anonymous’s picture

Yes! This worked for me too. When I commented it out the warning disappeared. Interestingly, uncommenting it has not brought the warning back. Thanks @RaisinBranCrunch.

Edit: the warning came back. Apparently that line has to be commented out.

vihuarar’s picture

It worked for me too.. I think Drupal should have a warning or something like that...

onejam’s picture

Just curious? how did that line:

$settings['skip_permissions_hardening'] = TRUE;

ended up in your settings.php file? because when you install Drupal, it creates a settings.php file for you and that line does not get added to settings.php.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

Anonymous’s picture

It's in example.settings.local.php which you can copy to settings.local.php which enables some local development override configuration features.
See https://api.drupal.org/api/drupal/sites!example.settings.local.php/8.2.x

onejam’s picture

Thanks

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien