Can I rewaken $CFG->dirroot?

Can I rewaken $CFG->dirroot?

by Visvanath Ratnaweera -
Number of replies: 8
Picture of Particularly helpful Moodlers Picture of Translators

In the old days there was a $CFG->dirroot which pointed to the Moodle code directory. It became obsolete since Moodle finds it out from the HTTP request. Can I rewaken the old dirroot?

I saw that $CFG->dirroot is used in the code for various things. My "dirroot" could have a different name. The question is, can I set $CFG->something to a directory, so that Moodle will take that directory as its root? Without causing a major upset in the code, I mean.
wink

Average of ratings: -
In reply to Visvanath Ratnaweera

Re: Can I rewaken $CFG->dirroot?

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I'm not quite sure what you mean by "in the old days" - $CFG->dirroot still points at the code directory and has never stopped doing so (unless there is something very strange that I've been missing every time I've used it).
In reply to Visvanath Ratnaweera

Re: Can I rewaken $CFG->dirroot?

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators
you know you've been around for a while when you are still setting dirroot in config.php smile - it's been ignored in config.php since Moodle 2.0 as part of MDL-22546

it doesn't get it from the http request - in 3.2 versions and higher it uses the PHP predefined constant __DIR__ - it older versions 2.0 -> 3.1 it used dirname().

So - you can set it in config.php but it will just get ignored/overwritten.

I just checked my local machine and our deployment scripts and we're still setting $CFG->dirroot in some of our config.php files here - might get round to stripping that out at some point...
Average of ratings: Useful (2)
In reply to Visvanath Ratnaweera

Re: Can I rewaken $CFG->dirroot?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Many thanks for your time (while I was sleeping)!
wink

@Davo, my understanding is that one can set a $CFG->dirroot, but since Moodle 2.x it will be ignored!

@Dan, MDL-22546 - what a short and sweet trouble ticket!

Thanks for the correction - PHP dirname() and __DIR__. So the short answer is, since Moodle 2.x no point in setting a $CFG->dirroot.

But there is hope, what I wanted to might work without a (forced) dirroot. Need to do some testing.

@Ken, the Why? I was trying to find the best answer for a support enquiry (and learning on the way). The scenario requires a fleet of very small Moodle instances, kind of low cost create and delete Moodle sites. Reminded me of a trick some installers do, keep one code directory and separate the database and moodledata by checking the HTTP_HOST web server (in this case Nginx) variable.

I know, I know, Docker is the answer. This is a low profile, low prio enquiry. Paradigm changes can wait.
smile

@all, I know that short-cut breaks PHP CLI scripts. Apart from that was there a security issue?
In reply to Visvanath Ratnaweera

Re: Can I rewaken $CFG->dirroot?

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators
yeah - a few people try to use HTTP_HOST to build wwwroot in the config.php - take a look at some of the complaints from people using bluehost as a provider - you run into all sorts of issues.

The biggest gotcha is that if you use HTTP_HOST you must not do anything with Moodle via CLI - as the http_host doesn't exist. That includes things like Cron/upgrade/install/deployment scripts etc - if you run cron on the cli with http_host, bad things happen to emails and you end up with broken links being sent to end users - also other edge cases like saml2 authentication won't work correctly when you're using HTTP_HOST.
Also - make sure you don't set "pathtophp" - as that's basically the same as letting things run on the cli....

I heard of a Moodle site that accidentally broke their production site completely because they ran an upgrade via cli on a staging site, and it picked the prod db because it was using some hacks based on HTTP_HOST - their site was down for about 4 weeks while they tried to restore it all from backups.

So - if you do go down that track... be really really really careful.... smile
Average of ratings: Useful (2)
In reply to Dan Marsden

Re: Can I rewaken $CFG->dirroot?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi Dan

> if you do go down that track... be really really really careful....
smile

Seriously, I can follow the dangers you described in clear detail, and remember myself warning others. For the experiment I am doing, for "a fleet of very small Moodle instances, kind of low cost create and delete Moodle sites", the stakes are not high.

I did a quick test and can confirm that there is no point in setting $CFG->dirroot in config.php. It is overwritten. It is the "require_once(__DIR__ . '/lib/setup.php');" line in config.php doing this, I suppose. Anyway, setting wwwroot from HTTP_HOST and assigning different databases, dataroots, etc. works the way, I wanted, without worrying about dirroot. It is also clear, there is only one Moodle directory tree.

What I would like to know is whether there are documented security issues in this approach.
In reply to Visvanath Ratnaweera

Re: Can I rewaken $CFG->dirroot?

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

You'd probably want to check http_host against a list of known domains.. and validate/sanitize it - theoretically a user could add a local entry for moodle.org pointing at your server IP address (or a domain they control) and if they can also trigger cron, could make it send email from your server with their domain in various links.

I can think of a few ways I could attack the security of a site by getting it to use a domain I have control over.

Average of ratings: Useful (1)
In reply to Dan Marsden

Re: Can I rewaken $CFG->dirroot?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi Dan

Got it! Sure I will react only to "my" domains, i.e. validate/sanitize HTTP_HOST.

Relieved to know that there are no other simple attacks. I am not worried about sophisticated attacks. This is for a less privileged / less demanding group - and the domain (it'll be sub-domains of a single main domain) won't be mine. Will pass a full danger report to them and get their written OK as a promise not to complain.

From what I saw in my quick test today, this approach will be very valuable to them. Good Karma is never lost.
wink