Permissions of `sites/default/files` and `settings.php`

[Muffinman]

Hi,

I'm wondering what the thought process was behind setting the sites/default/files dir to 777 permissions, and the settings.php to 644? It seems to be a insecure to have as a default?

Surely it's better to have something a bit more restrictive like 700 / 600 and then let the user open up the permissions further if required?

I'm sure many people will miss the console messages and leave their DB details globally readable.

[garrensweet]

I have to agree with @Muffinman here. I think that instead, you should have the sites/default/files set to 755 and the settings.php set to 400.

Also, pre-packaging this with something like https://github.com/vlucas/phpdotenv so we can easily manage our environment specific dependencies would be amazing.

[Muffinman]

Yeah we actually include dotenv in our drupal projects and just put the following in our settings.php / settings.local.php file.

$dotenv = new Dotenv\Dotenv(dirname(DRUPAL_ROOT));
$dotenv->load();

$databases['default']['default'] = array (
  'database' => getenv('DEV_MYSQL_DATABASE'),
  'username' => getenv('DEV_MYSQL_USERNAME'),
  'password' => getenv('DEV_MYSQL_PASSWORD'),
  'prefix' => '',
  'host' => 'localhost',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);

[webflo]

I get the concern about the permissions but Drupal will adjust it automatically during installation and bootstrap. see drupal_verify_install_file() in system_requirements().

[pheski]

Please be patient with me because I am in over my head, but...

I have had two instances in the last 3 days where my ISP sent me a security warning that I had insecure (777) directory and file permissions: sites/default/files/php and sites/default/files/php/twig.

Fearing that I had been hacked, I removed all the files and dropped everything from the database, created a new username and password and reinstalled. Several hours later, they sent me the same warning. The changed all those directories to 755.

Drupal 8.2.5 on DreamHost VPS. (I have had no problems with 3 Drupal 7.5 sites on the same server.) I added the Mayo 8 theme and the Admin Toolbar and Extra tools, but otherwise have not extended the site.

Is this normal behavior. Are these normal permissions?

Thanks.

[DavidRothstein]

settings.php needs to be writable by the web server during install, so what the code in this project is doing seems correct for that.

For sites/default/files, though, it needs to be writable by the web server forever, so normally it would make more sense for the web server to own that directory (and then it can have more restrictive permissions). Is there a reason the code in this project needs to create that directory manually, vs just letting the Drupal installer create it when it runs?

[Muffinman]

Most hosts these days are running php-fcgi anyway, in which case the web user and the ftp user are one and the same.

777 perms just bring in the potential for security issues where there was previously none. It's really not a great issue because the core should the correct the permissions on first page load, but why have the risk if we don't need to?

[JorisVanEijden]

Another problem is that the current code blows away any setgid from the parent dir.

[webflo]

It looks like we are trying to support multiple use-cases with ScriptHandler::createRequiredFiles. I never had those issues, because the script does not run on my production server it runs in a CI process instead. The deployment script takes care of proper permissions on the production system.

[paulvandenburg]

I've added a PR to solve this issue. I'm also of the opinion we shouldn't set these broad permissions by default, regardless of if Drupal fixes it. Using 777 permissions (or 666 for files) is a bad practice and a signal of a misconfigured webserver or dev environment.

I've let the group permissions maintain their write access, because that can be a reasonable expectation in some setups.

[AlexSkrypnyk]

This is still relevant for 10.x and 11.x