6

using Drupal 8.8.1

composer require drupal/{{ any package }} returns

Installation failed, reverting ./composer.json to its original content.

[RuntimeException]                                                           
Could not delete {{ ... }}/web/sites/default/default.services.yml

how are people handling this issue?

  • 1
    note to others: be aware of the security implications of the answers proposed so far as described in comments – Kay V Jul 5 at 0:54
7

Make your "local" machine work as intended

This approach will fix the issue on your local machine. The default .gitignore will limit the change to your local (it will persist on your local without affecting anyone else; don't make this change to settings.php to avoid affecting other instances, including PROD).

Steps

  1. enable settings.local.php (here are the instructions from the docblock in settings.local.php):
 * To activate this feature, copy and rename it such that its path plus
 * filename is 'sites/default/settings.local.php'. Then, go to the bottom of
 * 'sites/default/settings.php' and uncomment the commented lines that mention
 * 'settings.local.php'.
 *
 * If you are using a site name in the path [... read about exceptions in file]
  1. set file permissions to allow user to write to the file:

    $ chmod u+w {name_of_docroot}/sites/default

  2. find and change $settings['skip_permissions_hardening']; make it = TRUE;

Step #3 tells Drupal not to reset permissions on the default folder only on your local, and allows you to work more smoothly with composer on your local without loosening permissions on any other copy of the codebase.

| improve this answer | |
  • Makes sense. You should only make changes to web/default/ on your local, so it's logical to keep local permissions that allow changes to that directory while continuing to 'harden' permissions everywhere else. – lacuna Jul 5 at 1:04
5

This command will fix it temporarily:

chmod u+w web/sites/default

But Drupal will harden permission again soon. To turn it off add this to settings.php:

$settings['skip_permissions_hardening'] = TRUE;

Source: https://www.drupal.org/docs/develop/using-composer/starting-a-site-using-drupal-composer-project-templates#s-troubleshooting-permission-issues-prevent-running-composer

| improve this answer | |
  • 1
    This answer adds some useful details - thanks for posting it. That said, naturally it doesn't seem like you'd want simply to turn off hardening as part of your generally applied solution. How about updating the answer to specify doing this in settings.local.php? – Kay V Jan 30 at 11:59
  • How about to discuss axiom that permission hardening has some sence? What are realistic cases where it protects something? – Bobík Jul 6 at 11:29
  • Having seen how hard the Drupal community works at determining and implementing best available security settings, I believe default features are good to preserve unless I have extensive expertise in the alternatives. Since much of Drupal QA assumes defaults, odds are even higher there's a big advantage in maintaining them. Whether this particular setting is extraneous, @bobik, I'm not qualified to take on, tho I certainly hear your point. Thanks for the follow-on discussion! – Kay V Jul 6 at 18:20
  • Good point, usually I use the same argument. But if I see that anywhere in docs the reason is not properly described I am skeptical. In this case it seems also like some common created in ages of primitively secured shared hostings. I also can imagine a lot of attack vectors what will work even with hardening and none what hardening can stop on current good hosting. And if someone use some primitively secured hosting than this hardening is probably his less important problem. – Bobík Jul 7 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.