- Make sure the site can be still installed and upgraded without regressions, new plugin can be installed and a plugin can be upgraded (altering version numbers to trigger upgrades should be enough).
Regression tests: Make sure the site can be still installed and upgraded without regressions, new plugin can be installed and a plugin can be upgraded (altering version numbers to trigger upgrades should be enough). Functionality tests: Define `$CFG->upgradekey` in the config.php. Make sure that when you attempt to upgrade the site via the web UI, the user must provide the valid upgradekey value. The non-admin user should have no access to any information regarding the site and/or plugins versions. Check that the $CFG->upgradekey can be provided via admin/cli/install.php script
- Define `$CFG->upgradekey` in the config.php. Make sure that when you attempt to upgrade the site via the web UI, the user must provide the valid upgradekey value. The non-admin user should have no access to any information regarding the site and/or plugins versions.
- Check that the $CFG->upgradekey can be provided via admin/cli/install.php script
Reported by Don Schwartz <email@example.com> by email on Tue, Jul 14, 2015 at 4:59 AM
Moodle 2.8.7 and 2.9.1
tested on sites requiring both Http and Https
We discovered that if we have plugin, block specially, that needs installing or upgrading, the plugins overview page is shown to anyone who knows the address.
The test: I upload a new block to webroot/blocks
Visit site in a non logged in browser such as IE
I see the plugins overview and can update the moodle database before being redirected to login.
Without logging in, I go back to chrome and verify that the install and update has occurred. This happens if any plugin needs updating, not just new installs.
I didn't want to post in the tracker even though it sounds like it would hide it.
This exposes all plugins, versions, etc. Plus allows an update where one may not intend to yet.
I hope I'm missing something.
Reply by marina
There are some "major" upgrades of Moodle that require upgrade process to run before any user can use the site. In those cases any user (even guest) is redirected to the upgrade page. When I say "major" it does not necessary mean upgrade between major versions, like 2.8->2.9. This is why the upgrading instructions tell to put the site in maintenance mode before updating the code - https://docs.moodle.org/28/en/Upgrading
Unfortunately I noticed that our documentation on installing plugins does not mention it - https://docs.moodle.org/28/en/Installing_plugins. We will correct it asap.
Thanks for bringing it to our attention, I can not agree that this is a security issue in Moodle, nobody should be using the site when any upgrade is pending. We definitely need to fix the documentation though.
and finally replies by myself:
thanks for contacting us in a very responsible way. As far as I know,
Moodle has been always working like this, triggering the database
upgrade (including the installation of a plugin) on the first incoming
request from any source.
The code deployment and running the database upgrade is considered as
once step. There is not a valid case for "plugin code was deployed but
we did not want to run the upgrade" supported.
I do admit this is a potential for sensitive data leaks and we should
open a tracker issue for it. On the other hand, it must be said that the
list of installed plugins and their versions is not something we can
effectively hide from those who are looking for it. There are other ways
how to get know it.
I'll be happy to discuss this issue and possible solutions in the
tracker. Thanks again for contacting us.
and then again
Actually, I just tried it on my own and Don is right. We expose too much. We need the issue tracker.