I'm getting warnings from my ISP host that files in /sites/default/files/php/twig/ have the world writable bit set, and that I may be compromised. Digging in, it appears to me that Drupal is doing this on purpose and I'd be interested in a sanity check from others.
The files in question have names like <hash>.php and are in directories of the form <number>blah.html.twig<hash> and also the .htaccess. Inspecting their contents, they don't appear suspicious, and appear to be a 'compiled' version of the twig files. If I do a cache clear, they all go away and come back which further leads me to believe that they're all fine. Changing passwords has also had no effect on these, they comeback anyway.
The site appears to run fine with only owner and group write set, but later it picks up world (aka other) write set.
Now an argument can certainly be made that allowing world write to these is OK. An attacker would need to be logged into the machine and be able to guess the hash. Very, very unlikely. The hashes are far stronger than my password, and it's pretty darn strong.
Is this expected behavior? Can I do anything about it so I can stop getting warnings?
Core and all modules are up to date.
Drupal 8.2.5
Comments
=-=
Why are there theme files in your files folder? .htaccess is supposed to be in your files folder but should have been set at 644 I believe.
Sorry, I misspoke, as well as
Sorry, I misspoke, as well as not thinking about html markup. I gave the directory name. The files are <hash>.php, they reside in directories named blah.html.twig_<hash>.
Here is an example:
sites/default/files/php/twig/9a2bf118_select.html.twig_8d731d15ed2ad86fb4c1c9032513b4afc20acab4ae93d436e2f523a3791a4aed/e65e2c30b01ed2d5e861894ff2837c23dc9bfb171947fb2338d130dc4f149024.php
If the file was 644, it would all be good, but the ISP is understandably warning me about writable scripts.
=-=
you can change the permissions of the files and folders using the hosts file manager or an FTP tool, or the command line etc. The host really could have provided you with that information when they alerted you of the writable files. You've not taken the time to list modules installed or anything of the sort so I'm not sure what is generating those files but something is.obviously is as they aren't default files but I'd certainly take the time to chase that answer down.
I should have pointed out
I should have pointed out that I've changed the permissions, but the problem comes back on cache rebuilds. Although it appears that it's only for some of the files*. (The ISP didn't need to tell me how to change the permissions, I've got 30+ years of *ix experience under my belt.)
I'm quite sure that they are default files. Generated from the twig files by the system as part of the normal operation. Check your system, you'll find files just like them. You know how you may need to clear cache during development? These files are the cache. Or at least part of it.
(Edit: From the Twig debugging documentationrefers to these files:
As to installed modules, I have Admin_toolbar, Entity, and Profile. That's it. All running latest and greatest.
*I'm developing a theory based on the fact that it's only some files. I suspect that something is failing sporadically during the compile of the twig files and not getting as far as correctly setting the permissions. Time to start digging through the source code.
This issue has information
This issue has information about why this is the case.
Indeed, thank you. I've
Indeed, thank you. I've posted a comment there although I suspect it will be rejected. The nice thing about open source though is that I've modified my site and can continue working.
True.
True.
What modification? Thanks.
What modification?
Thanks.
My recommended changes to permissions
I've changed three files. I think the first is the only important one. Basically I went for all 777's outside of the tests trees, and made them 775.
core/lib/Drupal/Component/PhpStorage/FileStorage.php
- protected function ensureDirectory($directory, $mode = 0777) {
+ protected function ensureDirectory($directory, $mode = 0775) {
core/modules/simpletest/src/WebTestBase.php
- chmod(DRUPAL_ROOT . '/' . $this->siteDirectory, 0777);
+ chmod(DRUPAL_ROOT . '/' . $this->siteDirectory, 0775);
vendor/twig/twig/lib/Twig/Cache/Filesystem.php
- if (false === @mkdir($dir, 0777, true) && !is_dir($dir)) {
+ if (false === @mkdir($dir, 0755, true) && !is_dir($dir)) {
Much appreciated. Thank you
Much appreciated. Thank you very much. One can hope that in future 8.x.x updates this will be changed so we don't have to re-tweak this with each update...
I had this problem on an 8.8.1 site and this fixed it.
I had this problem on an 8.8.1 site and this fixed it. Thanks!
still a beta
Dozens of these sorts of oddities and problems with Drupal 8 are why I consider Drupal 8.x to be still a beta product.
spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...
Drupal 8 as beta
I'm inclined to agree.
In my conversation with my hosting ISP (DreamHost) here is their position:
I think their position is reasonable and I have submitted this as an issue, in hopes that the developers will change this in future updates.
So far, so good.
It's been 20 some hours, aka long enough that Dreamhost's security scans should have run (I'm on DH also), and no complaints from their security scans. I am cautiously optimistic that my trivial fix is all that is required.
I also think their position is eminently reasonable.
I agree that their position
I agree that their position is reasonable (and I told DH that). DH suggested I consider a private server, but I do not consider myself competent enough for that. I have made the changes you describe, but only this morning.
The down side is that we will have to re-do the changes after any 8.2.x updates, unless Drupal incorporates the changes in core. I can live with that, as it takes about 2 minutes.
Thanks for your help.
In my Drupal 8.8.2 site I was
In my Drupal 8.8.2 site I was a bit cleaning up and so I stumpled over the same problem. As a follow up I also stumbled over this thread. Now I know that this seems a "normal" behaviour in Drupal (thank you all here :) ), but a bit scaring that the (IMO major) problem isn't solved after so many years...
Drupal and Twig both say
Drupal and Twig both say there isn't an issue and it's a "won't fix" thing. I agree that there isn't actually a security issue, the hashes work but there is no way to tell the automated scanners that it's fine. Three years later and I manually change the source code from 777 to 755 on every upgrade.
The current files that need to be changed are:
core\lib\Drupal\Component\PhpStorage\FileStorage.php
vendor\twig\twig\src\Cache\FilesystemCache.php
Well I'll try if my webhoster
Well I'll try if my webhoster accepts 775 as directory permissions. Unfortunatelly I'm not able to write a contrib module or a patch for the changes you sugessted, but imo it would makes sense,
Twig cache
The PHP files are compiled Twig templates and the .htaccess file protects them from public access. You can disable caching of compiled twig templates by setting this service parameter to FALSE.
You find this in sites/default/default.services.yml, which you have to rename to sites/default/services.yml to activate it.