Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-69337

Inconsistent checks and/or docs regarding "dataroot" location being secure

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.9.1
    • Fix Version/s: None
    • Component/s: Installation
    • Labels:
      None
    • Affected Branches:
      MOODLE_39_STABLE

      Description

      Environment

      A Debian 10 web server where we've chosen the software stack and done the configuration ourselves (not automated by something like cPanel or Plesk) and includes Apache 2.4 and PHP FPM 7.3.  There's also a PHP based interface (Froxlor) which writes out simple vhost and php.ini config files for novice users of the system (individuals and non-profits/charities who we give free hosting to).

      Problem

      In Apache terminology, the "DocumentRoot" path of a site on this box looks like this...

      /var/customers/webs/username/example.com/

      If Moodle is extracted to run directly under that path, by default the installation wizard wants the "Data directory" to be...

      /var/customers/webs/username/moodledata/

      The trouble (and quite sensibly) is that the open_basedir allows only these paths...

      /var/customers/webs/username/example.com:/var/customers/tmp/username:/usr/share/php:/usr/share/php5:/tmp

      So this "Data directory" (which I'll just call moodledata from now on) can either go within the DocumentRoot or possibly inside that tmp directory.  That tmp directory isn't a very good candidate for persistent data however as it's accessible to all sites under that username, full of PHP session files and it's also used by PHP variables "upload_tmp_dir", "session.save_path", "TEMP", "TMPDIR" and "TMP".

      Choices

      a) Disable open_basedir.

      No, this should be obvious why.

      b) Add a single additional static path, appended to the end of the current open_basedir.  This would mean an entirely different php.ini configuration (which are managed like a template by Froxlor in our case)... just so this one instance of Moodle can use it.  Another copy of Moodle couldn't even use the same php.ini either, it would require yet another one for another path!

      When we do this... oddly even though moodledata is outside of the DocumentRoot... The Moodle installation wizard automatically creates a .htaccess file inside it with the below contents... which is crazy as since they're OUTSIDE of the DocumentRoot, surely this won't ever be processed?

      deny from all
      AllowOverride None
      Note: this file is broken intentionally, we do not want anybody to undo it in subdirectory!

      c) Put moodledata inside the DocumentRoot and secure it

      None of the issues I've seen on this tracker address this directly without also muddying the issue with other factors.  This is also not a duplicate bug because this issue (keep reading until the bottom) is the confusion regarding this matter.

      I know this has been a contentious idea but this also shouldn't be a heinous crime if done securely...

      Not only does the installation wizard not state it shouldn't be done... it just calls for the directory to be writable/readable and not be accessible over the web (surely satisfied with a .htaccess file if using Apache).  But also the current Moodle docs talk as though this is allowed...

      https://docs.moodle.org/39/en/Installing_Moodle#Create_the_.28moodledata.29_data_directory

      Yet if you create an empty moodledata directory inside the DocumentRoot and put a valid .htaccess file inside.  Even if the contents of that .htaccess file are exactly the same as the one we've seen the installation wizard itself write out above!  You get...

         Dataroot location is not secure

      This is clearly a ** lie **.  I even tested it by putting a text file and a php script in to that directly and got HTTP error 500 like it's supposed to.

      Pick a bug (just one)

      Either...

      1) Fix the security check so it knows it's secure when it is... perhaps by writing a file to that location and check (by HTTP request) it can't be read.

      Additionally if we're running under Apache (easy to check) and the specified "Data directory" doesn't exist... the installer should just attempt to make it and stick a .htaccess file there, which we've already seen it's capable of making anyway!

      Or...

      2) Prevent Moodle from ever working if moodledata is inside the DocumentRoot

      This'd mean (as I can see on the support forums) this issue will continue to frustrate many people with cheaper web hosts that can't or won't alter open_basedir and only allow access to the DocumentRoot

      But if this is the decision for paranoid security reasons... then actually commit to it.  Moodle itself (not just the installation wizard) should always check if the "Data directory" (e.g. moodledata) is a subdirectory of the DocumentRoot... and... if it is... ** fail to function **.

      This would then prevent someone from going around the installation wizard afterwards, moving the directory and editing the config file.  Additionally the installation wizard text should make it clear it can not be under the DocumentRoot and the online Moodle docs need to say the same.

      Summary

      Right now... the text shown during the installation wizard (plus the official Moodle docs)... and the crazy things it does to check and/or the .htaccess files it creates (which then wouldn't be read?!)... is just completely inconsistent.

      Thoughts?

      Obviously I hope people that will see the bug is number 1, not 2... as this just makes it easier for more people to use Moodle while not compromising on security.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            Lantizia Steven Maddox
            Participants:
            Component watchers:
            Matteo Scaramuccia, Andrew Lyons, Dongsheng Cai, Huong Nguyen, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated: