Consider supporting Package Manager's new direct-write mode

Letting a public web server write to code directories is a huge security risk. It's a hacker's dream. On local environments it's not an issue.

The idea that everyone is going to have a git workflow with a dev site and a developer running ddev on a local machine is a fantasy. If the idea is to appeal to people who aren't going to use the command line, then the only safe alternative is something like https://www.drupal.org/project/sheephole_helper → Since it's open source, what's the objection to using that instead of encouraging an unsafe server environment?

Letting a public web server write to code directories is a huge security risk. It's a hacker's dream. On local environments it's not an issue.

That's why direct-write mode needs to be enabled per environment (in a setting), and it explicitly warns about being risky and not recommended on production.

Project Browser should opt into it specifically to support local development.

Those who've worked with smaller clients will realize what will happen: they'll take the risk. Then, some will get hacked. Then, Drupal will get a bad reputation about being insecure.

There are still lots of sites running D7/8/9, including major sites like large universities and government sites. There are countless thousands of sites running vulnerable versions of WordPress. They're taking a risk or they don't know any better.

Drupal should make it as easy as possible to be as secure as possible. That's a strong selling point. Drupal should not make it easy for people to create insecure environments.

To clarify something: just because Project Browser opts into direct-write support does NOT mean it is automatically enabled!

Direct-write has a two-part opt-in process. From the change record → :

To operate directly on the live site, two conditions must be met.

1. A new setting, package_manager_allow_direct_write, must be set to TRUE.
2. Individual subclasses of \Drupal\package_manager\SandboxManagerBase must have the \Drupal\package_manager\Attribute\AllowDirectWrite attribute applied to them.

Project Browser will not, by supporting direct-write, be assuming that all environments are local. The site owner needs to actually allow direct-write to be used at all by altering settings.php.

The best practice here would be to enable it in settings.local.php only, which should not normally be deployed to a production environment. Therefore, done correctly, local environments will be able to use direct-write (which is what it was intended for), and production environments should not.

Of course, you as a site owner could enable it on a production environment too, which is something we explicitly warn against. If you do that anyway, against our warnings, you're on your own. Drupal takes this secure-by-default-but-you-can-break-it-if-you-try approach in many places.

In my opinion, yes, in this case the potential benefits outweigh the risks. I support adding this functionality. The real risk with PB direct-operating on the codebase is actually during activation (turning on a bad module that whitescreens your site). This is simply eliminating a copying step and improving performance, especially for things like local environments. For example, I personally would probably use PB to add and enable modules rather than Composer directly, and I'm a seasoned Drupaler. BUT, I don't right now because it's slower.

The only risk I do see with operating on a live site is if our Composer operation results in upgrading a module in-place. But, we have other ways to potentially handle that (an interstitial "here's what operations will happen," modal for example).

+1 on this feature. I think it's needed. FWIW, I (and Leslie) do NOT support surfacing this setting in the UI.

FWIW, I (and Leslie) do NOT support surfacing this setting in the UI.

Direct-write is not a choice that can be surfaced in the UI. That would imply it is a configuration flag, which it is not. It has to be enabled by a developer -- someone with access to the code base, who can alter settings.php (or, better yet, settings.local.php physically). That's all by design.

woohoo! huge time-saver. ship it

Automatically closed - issue fixed for 2 weeks with no activity.