Allowing updating your codebase in production could be open some potential attack vectors.
Currently the update module in core also has this problem. To mitigate this the Update module allows you to set allow_authorize_operations = FALSE in settings.php which turns off this functionality.
Once Automatic Updates is in core there won't easy way to prevent a user with the correct permissions from turning on the Automatic Updates module and being able to update core, and other projects once we support updating them.
Consider adding a global "kill switch" mechanism in Package Manager, a boolean in settings.php like package_manager_disable = FALSE, which if set to TRUE would make all Package Manager operations throw an exception. That's one option;
Or we could just add global kill switch for Automatic Updates and other modules could follow the same pattern if they want to.
Decide how we should do this. Then do it.
TBD
TBD
TBD, but probably none.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
tedbowComment #4
phenaproximaI took a stab at implementing this kill switch by disallowing the apply operation if a particular setting is TRUE. I'm not convinced we need a kill switch for the create/require/destroy stages, since those don't affect the live site.
Assigning to @tedbow for review.
Comment #5
tedbowI think we should seek input from the security team on this to see if we actually need it and what form it should take if we do. One difference between `
allow_authorize_operationsand what we could create here is the Update module has other functionality like providing a list of available updates. We don't provide other functionality so it might make sense to prevent AutoUpdates from being installed at all if package manager can't perform operations. but for other modules it might make sense to allow the module to be installed because it might have other functionality that is not dependent on package manager working. For instance Project Browser might fallback to just showing the composer command if this switch is setComment #6
phenaproximaTagging for security review so we remember.
Comment #7
tedbowPostponing because we need more info. I made a couple suggestions but I am not sure it is worth working on this more if aren't going to add the feature
Comment #8
tedbowI think this is something that could happen after we are in core. it would even be feature added after beta I would think.
So since I am the only one we really thought this was important lets bump to minor
Comment #9
tedbowComment #10
tedbowComment #11
wim leersIs this still relevant?
Clarifying current status after ~5 months of silence.
Comment #12
gregglesI found this issue while looking for a duplicate before creating one.
I agree with the issue summary.
Yes, I would say it's important for there to be a way for a site developer, with access to settings.php, to disable the ability to update modules or install new modules from remote locations. It's either very similar to allow_authorize_operations and should be documented/placed in a similar location, or should rely on allow_authorize_operations directly.
Updating the IS to remove some ambiguity about whether this is a good idea.
Comment #13
catchMoving this to the core queue, not really a feature.