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
chmod 444 /sites/default
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
Still the same...
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
insteadchmod 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
Also, make sure your default
Also, make sure your default directory is chmod 555
-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien
Still the same... check the
Still the same... check the permissions here:
http://es.tinypic.com/r/11t7n6p/9
I did
chmod 555 default
Yep, that all looks fine so i
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
I made adrush cache cr
I made a
drush cache cr
but still the same...do you think that this is a bug that I should report?
No, it's not a bug.
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
Yep.. is the same
Yep.. is the same installation...
Let's wait some time... maybe somebody else give us a clue...
Thanks @duvien
Seeing the same issue
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
First of all the Drupal
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.
I reported the bug here:https
I reported the bug here:
https://www.drupal.org/node/2820620#comment-11739167
Your permissions are wrong.
@pferlito - Your permissions are wrong. In step 5 of the docs, it says:
@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
@duvien please post a link to
@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.
The link to the doc is the
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
Yes, I tried it that way also
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.
Skip Permissions Hardening
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.
That may be it!
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.
Yes! This worked for me too.
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.
It worked for me too.. I
It worked for me too.. I think Drupal should have a warning or something like that...
Just curious? how did that
Just curious? how did that line:
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
It's in example.settings
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
Thanks
Thanks
-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien