Include ProcessWireUpgrade as a core module

[jmartsch]

Please include the ProcessWireUpgrade module as a core module. I use it in various PW installations without problems. I think easy updating should be part of a nice CMS.

In my opinion, it should also be installed/activated by default.

[adrianbj]

I think Ryan stated somewhere that he won't do this because he doesn't think it should be installed on production sites because of the security issues with having the needed directories writable.

[teppokoivula]

I've stated multiple times that I won't allow the web server write to directories with executable code, and particularly core files – yet now I see that I'd also given a thumbs-up for the duplicate issue #155.

This is one of those cases of "Ryan knows best": I wouldn't mind seeing this feature in the core myself, but of course it could only work for setups where permissions are (in my opinion) too lax from a security point of view. Tricky one 😅

[jmartsch]

I dont understand why this should be security issue. The module installer also has access to write files and other CMS also include an updater which modifies the core files. So why is it not a security concern for them?

[teppokoivula]

@jmartsch, the short answer to the "why is it not a security concern for them" question is "it most definitely is." A lot of hacked sites I've come across have been a result of a couple of factors:

1. Someone gains the ability to execute code (or modify executable code) via the system. Often this is a result of a piece of vulnerable code on the site – plugin, library, site-specific custom code, etc. – but sometimes it's via a built-in feature that was designed to give high-level users access to code.

(In the latter case attacker might've gained credentials somehow, or they might've found an issue leading to privilege escalation, OR the attacker might even be a legitimate, disgruntled admin.)

2. The web server has write access to a number of files, including core and/or plugins/modules, so the attacker can now overwrite any given part of the system, doing vast amounts of harm with little effort. From here the issue escalates quickly.

Now, if web server only had access to a single directory that doesn't normally contain executable code – say, site/assets/ – they would only be able to add or overwrite content of that directory. Though still a major issue, this would've already notably limited their ability to cause harm.

Module installer is a limited case: it only has access to modules, not core files. That being said, in my opinion enabling module installations via the site is a major issue in itself. Again this is purely my own opinion, but I would recommend against enabling it. I get why it's there, and I get why it's important, but from a security point of view it's a real risk.

I hope this answered your question. When you say "other CMS", I can think of a few that have this sort of approach, and I know of a lot of examples where this has backfired, but I'd rather not start pointing fingers here 😄

---

Note that the reason why I said that this is "a tricky one" is that we'd have to weigh in the benefits and the drawbacks. Which is more important: easy updating via web GUI, or securing permissions? In this regard we can't rely on the decisions made by other systems either – their circumstances are different.

I did also mention that I wouldn't personally be against bundling the updater with the core, as long as it doesn't need to be enabled/used. Still, having it around may result in more folks loosening permissions, which in turn may result in more problems.

Not an easy decision 😄