Automatic Updates currently asks admins to configure core files to be writable by the PHP user. While the update process itself is trustworthy, this enables vulnerabilities in Drupal, contributed projects, or dependencies to be exploited to modify core files. This is a serious problem in the real world that could negate the advantage of automatic updates.
Users who are comfortable with the command line can set up cron to run automatic updates as a user who has permission to modify core files. Yet if the command line is the only way to run updates securely, many vulnerable sites will never be fixed.
This problem was previously solved by the Update module. When updating contrib projects, if PHP did not have permission to change a contributed module, the Update module checked for file transfer backends. If one existed, authorize.php prompted for the user name and password of a user who had permission to write to the file system. No credentials were stored in Drupal, so an authorized user had to be present to modify files.
Changes notices and adds a prompt to the admin UI when user initiates automatic update.
| Comment | File | Size | Author |
|---|
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:
compare
Comments
Comment #2
heddnAutomated updates with a password stored-on-disk or in-a-script for ftp seems pretty in-secure too. At some level, updating the site is going to require some access to write to the disk. And the trigger for applying those updates can be a drush cron run as any system user via system cron. This approach would preclude the need for ftp credentials and work with the existing setup in this module.
There is a complicated set of issues around opcode cache if run via CLI and opcode is enabled, but there are some work arounds for that using https://github.com/gordalina/cachetool.
I'm inclined to close as works as designed, but let's see if I've mis-represented the problem in an overly simplified manner. For the mean time, moving to postponed.
Comment #3
darren ohYes, you misrepresented the problem. As noted in the issue description, it has already been solved in the Update module which prompts for an SSH or FTP password and does not store it. The feature is probably rarely used, so I can understand how it was overlooked. If the update can be triggered from the web, this is the only secure way to do it.
Comment #4
darren ohComment #5
darren ohComment #6
heddnI was envisioning that automatic updates happened without human interaction. I'm confused if we require humans to enter a password; because if we require humans, I don't consider that to be automated updates any more. And the point of this effort is to remove the human element.
Comment #7
darren ohThere is an admin UI for manually triggering the update. And if the update depends on cron, that can be triggered by any visitor.
Comment #8
heddnLong week with the virtual con... but if I understand your last comment, then you can do exactly that right now via drush and linux cron. There isn't a slick web UI to set things up, but that also helps with cross-platform compatibility as run-as on Windows vs Linux vs your platform of choice is going to be somewhat different.
For linux, just use its system cron to trigger
drush cron-runas your privileged system user.Comment #9
darren ohMaybe you're trying to say that the option to trigger the update from the web should be removed. As the issue description states, this is partly a documentation problem. Instead of warning users to make core files writable, notices should recommend the steps required to make it work without doing so. We really need to try to get more people to protect core files from modification by the web server. Currently the automatic updates initiative encourages the opposite.
If you don't want to work on it, just leave this issue alone and it can be my contribution.
Comment #10
heddnThanks for keeping with your feedback. Yes, we need to improve the docs and best practices/guidance around how to use this module. Let's do that!
Comment #11
darren ohComment #12
darren ohStarting a patch to get input.
Comment #13
darren ohComment #14
darren ohComment #15
darren ohComment #16
darren ohComment #17
darren ohComment #18
darren ohComment #19
darren ohComment #20
darren ohReadiness checkers are updated. Started adding code for authorizing file operations. Need to determine exactly what can run at the authorize bootstrap level.
Comment #21
darren ohComment #22
darren ohComment #23
darren ohComment #24
darren ohComment #25
darren ohComment #26
darren ohComment #27
darren ohComment #28
darren ohComment #29
dwwIf you intend to rely on the FileTranfser classes to do this, and you actually think that could still work, you need to speak up (quickly?) in #3491731: [META] Remove the ability to update modules and themes via authorize.php. The current MR there completely removes that entire API (along with authorize.php and related methods from system.module). Everyone (so far) thinks it’s legacy cruft that no one could possibly care about anymore and doesn’t even deserve to be deprecated before removal. 😅
I’m extremely familiar with the goal of UI-based updates for sites configured in depth. I have championed that approach since D6, and wrote the bulk of this code in the first place. You don’t have to explain to me how it works or why in principle it’s a good idea.
However, I’m no longer convinced that any site with httpd running as another user than the one who owns the files will be maintained by someone who is CLI averse. It’s only wild speculation, but my sense is the intersection of those two sets is vanishingly small, and not worth bogging down core with technical debt to support.
It’s absolutely worth making the UI play nicely with a cron-driven “sudo” step. That’s already been done. But actually requiring manually logging in via FileTransfer directly as part of the UI seems unnecessary.
Comment #30
dwwPoint 2 in remaining tasks is already done. Adding links.
Comment #31
dwwFor clarity, the “cron-driven sudo” step that’s already supported is not via Drupal’s hook cron, which “might be triggered by any user”. I/we are talking about good ole *nix crontab, and specifically setting up the script completely outside of Drupal.