Saludos. Iñaki.

Saludos. Iñaki.

Saludos. Iñaki.

I am not sure I like the option to remove the warning, many people either do not understand English enough (not all lang packs will have it translated) or click anything. If implemented it should be IMO user preference, not site setting. We have already discussed some ideas related to general notification framework, unfortunately there was not enough time to do that during 1.9dev last year

I agree that this security warning should be more annoying and visible - different CSS (red color?), bigger font (bold?), different wording.
The changes in installer is a good idea. The target="_new" is not strict and the <u> tag is not nice. Maybe the wording could be improved a bit.

assigning to Martin for final decision

But I posit that those savvy enough to do all those tricks don't need this check and the associated warnings. It's the non-technical people that use a shared hosting setup who need this. Specially if they use the-easy-to-setup but brain-damaged (wrt the final configuration) Fantastico installer.

Whether you make the option to remove the warning a site setting or an (admin) user preference, I don't really mind. As to the lang packs not translating the text, it'll be no worse than the current situation, where a user can be vulnerable and still not know it. So this can only be an improvement

Regarding the '_new', <u> tag and the improved wording, feel free to change it as much as you want. All I really want is the general functionality of the patch to be added to the core as fast as possible, so vulnerable people can get a warning of their current situation as soon as possible.

Saludos. Iñaki.

1/ July 2006 - Steve Lord reported that misconfigured sites are vulnerable - Google search confirmed this is a real problem

2/ August 2006 - I have proposed code that changed default (often not safe) dataroot location in installer and also added warning on admin/index.php, please note the admin/index.php is displayed right after installation and after EACH upgrade; Several people including Iñaki, TIm, Howard really helped to improve my solution.

3/ I have also done some more Google research at that time - it was really scary We have notified several large sites before the release.

4/ September 2006 - Moodle 1.6.2 released - the first version with warning included; after this many ppl asked in Moodle.org forums "how do I fix that new warning on admin page?"

I really like this patch, but:

• it helps only for sites that do upgrades - if I search for allinurl:moodledata/sessions I get around 1k of results and many of them are repeated hits, many of them show dates from 2006 - conclusion: warnings did not help to fix abandoned or not maintained sites
• not many people are upgrading to latest cvs nightlies or weeklies - conclusion: we do not need to rush the commits here, it should be enough to do it before next releases
• we must finalise the language strings before commit and coordinate this with translators - conclusion: we have to wait for ppl to get from vacations

I think you should remove the config.phpx file from the public_dataroot_19stable_6.patch file (and maybe change the passwords of the databases mentionned there).

saludos. Iñaki.

I would just suggest change the wording slightly on the admin/index.php warning (http://tracker.moodle.org/secure/attachment/14918/warning.jpeg) to:

SECURITY WARNING! Your dataroot directory is in the wrong location and is exposed to the web. This means that all your private files are available to anyone in the world, and some of them could be used by a cracker to obtain unauthorised administrative access to your site!

You must move your dataroot directory (/home/something/www/dataroot) to a new location that is not within your public web directory, and update the $CFG->dataroot setting in your config.php accordingly.

Saludos. Iñaki.

Petr

In /var/www I have a moodledata folder writable by the web server, and a symbolic link from moodle -> /home/tim/Workspace/moodle_head/. So in config.php I have

$CFG->wwwroot = 'http://tim.moodle.com/moodle';
$CFG->dirroot = '/home/tim/Workspace/moodle_head';
$CFG->dataroot = '/var/www/moodledata';

I believe this is insecure, but I don't see the admin warning.

(If I try changing $CFG->dirroot to "/var/www/1.9"; then I get told to change it back, which I think is good.)

Looking at the code in is_dataroot_insecure it is hard to see how to generalise it to cover cases like this (I know, why don't we try to find and parse the Apache config file ). Anyway, I just thought I should report what I am seeing.

as I said before, there are dozens of cases that can't be caught be this kind of checks. Using symbolic links like you do is one. Using 'virtual directories' (in IIS parlance, Aliases under Apache) or rewriting urls (with mod_rewrite under Apache or equivalent tools under IIS) are others.

You particular configuration could be detected by using the $_SERVER['DOCUMENT_ROOT'] value, and checking that $CFG->dataroot is not inside it. Of course this doesn't detect all the vulnerable configurations (aliases, url rewriting, etc.) but it puts 'another finger in the dam'.

Saludos. Iñaki.