Moodle has issued security updates including version 2.4.4 on May 15: https://moodle.org/mod/forum/discuss.php?d=228536 http://docs.moodle.org/dev/Moodle_2.4.4_release_notes Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
CVEs are now public for this: http://openwall.com/lists/oss-security/2013/05/21/1
Updated packages uploaded for Mageia 3 and Cauldron. Advisory: ======================== Updated moodle package fix security vulnerabilities: The assignment module in Moodle before 2.4.4 was not checking capabilities for users downloading all assignments as a zip (CVE-2013-2079). The Gradebook's Overview report in Moodle before 2.4.4 was showing grade totals that may have incorrectly included hidden grades (CVE-2013-2080). When registering a site on a hub (not Moodle.net) site in Moodle before 2.4.4, information was being sent to the hub regardless of settings chosen (CVE-2013-2081). There was no check of permissions for viewing comments on blog posts in Moodle before 2.4.4 (CVE-2013-2082). Form elements named using a specific naming scheme were not being filtered correctly in Moodle before 2.4.4 (CVE-2013-2083). http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2080 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2081 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2082 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2083 https://moodle.org/mod/forum/discuss.php?d=228930 https://moodle.org/mod/forum/discuss.php?d=228931 https://moodle.org/mod/forum/discuss.php?d=228933 https://moodle.org/mod/forum/discuss.php?d=228934 https://moodle.org/mod/forum/discuss.php?d=228935 http://docs.moodle.org/dev/Moodle_2.4.4_release_notes https://moodle.org/mod/forum/discuss.php?d=228536 ======================== Updated packages in core/updates_testing: ======================== moodle-2.4.4-1.mga3 from moodle-2.4.4-1.mga3.src.rpm
Version: Cauldron => 3Assignee: luigiwalser => qa-bugsWhiteboard: MGA3TOO => (none)Severity: normal => major
To get this up and running, it's similar to other web app packages. Simplest way: urpmi mariadb systemctl enable mysqld.service systemctl start mysqld.service mysql -u root mysql> create database moodle; mysql> create user 'moodle'@'localhost' identified by '<PASSWORD>'; mysql> grant all on moodle.* to 'moodle'@'localhost'; mysql> ALTER DATABASE moodle DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; mysql> exit; Then, edit /var/www/moodle/config.php, and in the empty single quotes for dbuser and dbpass, put 'moodle' for dbuser (or whatever user you created in the create user command in mysql), and the password you used in the create user mysql command in for dbpass. Then browse to http://localhost/moodle to complete the setup. There's a lot more documentation on using moodle at: http://docs.moodle.org/24/en/Main_page
Having some problems with installation x86_64. Initially it was saying it couldn't connect to the database. I tried various combinations of moodle, moodle@localhost, "moodle"@"localhost" etc in config.php with no luck. Created the DB & user with phpmyadmin and changed the collation type to utf8_unicode_ci there but still no luck. I thought there was maybe a missing require/suggest so installed php-pdo_mysql and restarted httpd and after doing so it showed the installer. Removed php-pdo_mysql and restarted httpd again and it again showed the installer so not sure what I did that made it recognise the database but got there in the end. It did show all requirements fulfilled in the config screen. During web based installation it encountered another problem though, below, I'll remove all traces and start again. Debug info: Table 'moodle.mdl_block_formal_langs' doesn't exist SELECT * FROM mdl_block_formal_langs WHERE visible = ? [array ( 0 => '1', )] Error code: dmlreadexception Stack trace: line 426 of /lib/dml/moodle_database.php: dml_read_exception thrown line 1023 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end() line 1211 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->get_records_sql() line 1162 of /lib/dml/moodle_database.php: call to moodle_database->get_records_select() line 30 of /blocks/formal_langs/block_formal_langs.php: call to moodle_database->get_records() line 39 of /question/type/preg/settings.php: call to block_formal_langs::available_langs() line 3031 of /lib/pluginlib.php: call to include() line 327 of /admin/settings/plugins.php: call to plugininfo_qtype->load_settings() line 6264 of /lib/adminlib.php: call to require() line 6284 of /lib/adminlib.php: call to admin_get_root() line 1445 of /lib/upgradelib.php: call to admin_apply_default_settings() line 180 of /admin/index.php: call to install_core()
Whiteboard: (none) => feedback has_procedure
I know this works and I've been using it in production for months. I don't know anything about phpmyadmin, so please use mysql commands like I showed above and show me your exact commands and config.php.
Whiteboard: feedback has_procedure => has_procedure
Bug 10328 & bug 10330 created for texlive/texlive-texmf errors noticed during installation.
I followed those exact commands before trying with phpmyadmin David, that's why I did so. The settings that worked in config.php were with dbuser 'moodle' $CFG->dbtype = 'mysqli'; // pgsql, mysqli, mssql, sqlsrv, or oci $CFG->dblibrary = 'native'; $CFG->dbhost = 'localhost'; $CFG->dbname = 'moodle'; $CFG->dbuser = 'moodle'; $CFG->dbpass = 'moodle'; $CFG->prefix = 'mdl_'; Seems fine this time though connecting to the database initially but produces the same error during web based installation. Error reading from database More information about this error <<== links to http://docs.moodle.org/24/en/error/moodle/dmlreadexception It is usually not possible to recover from errors triggered during installation, you may need to create a new database or use a different database prefix if you want to retry the installation. Debug info: Table 'moodle.mdl_block_formal_langs' doesn't exist SELECT * FROM mdl_block_formal_langs WHERE visible = ? [array ( 0 => '1', )] Error code: dmlreadexception Stack trace: line 426 of /lib/dml/moodle_database.php: dml_read_exception thrown line 1023 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end() line 1211 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->get_records_sql() line 1162 of /lib/dml/moodle_database.php: call to moodle_database->get_records_select() line 30 of /blocks/formal_langs/block_formal_langs.php: call to moodle_database->get_records() line 39 of /question/type/preg/settings.php: call to block_formal_langs::available_langs() line 3031 of /lib/pluginlib.php: call to include() line 327 of /admin/settings/plugins.php: call to plugininfo_qtype->load_settings() line 6264 of /lib/adminlib.php: call to require() line 6284 of /lib/adminlib.php: call to admin_get_root() line 1445 of /lib/upgradelib.php: call to admin_apply_default_settings() line 180 of /admin/index.php: call to install_core()
Maarten, do you have any idea why the database isn't working for Claire?
CC: (none) => alien
I'll try it i586 next.
i586 fails in the same way David.
Should say though that both these are when installing the current version rather than the update so ought to be repeated with the updated version which I'll do now. For both I have removed php-suhosin which sometimes causes problems with web package installations. Dropped all tables in moodle DB and restarted installation with moodle-2.4.4-1.mga3 from testing. The error still persists i586 & x86_64 (two different systems).
It is correct though, there is no table for mdl_block_formal_langs There are for mdl_block, mdl_block_instances & mdl_block_positions if that helps any.
Whiteboard: has_procedure => has_procedure feedback
this maybe be a stupid idea, but did you remove skip-networking and restarted mariadb? or can the app use local socket too?
(In reply to AL13N from comment #13) > this maybe be a stupid idea, but did you remove skip-networking and > restarted mariadb? or can the app use local socket too? It uses the local socket by default.
skip-networking is set, so it's connecting to local socket. It creates 152 tables ok, but is just missing that one to do with lang's, something to do with l10n maybe?
does the moogle install have any sort of logs to find out what query was used at install time to create this mdl_block_formal_langs ? or perhaps there's an sql file it uses?
Reproduced on an updated Mageia 3 VM with the /release version. I did test this before the release, so I don't know what changed to break this.
Just in case I hadn't tested it recently enough, I tested 2.4.2 and I'm seeing the same problem with that now. This isn't making sense.
Reproduced on Mageia 3 with 2.4.1. Reproduced on Mageia 2 also with 2.4.3, where this is currently running fine in production for me for quite some time. Not sure exactly when I last tested a new installation, but think it might have been early this year. Now this *really* isn't making sense.
OK Moodle 2.3.3 on Mageia 2 works. So I guess 2.4 broke something for new installations.
Missing requires or something ? does moodle pre-install check complain about something missing ?
CC: (none) => tmb
Hmm, OK no the problem isn't in Moodle it appears, but the preg plugin I added in the package, that's where the blocks/formal_langs directory comes from.
My 2.3.3 package had an older version of preg that didn't have formal_langs.
OK, so there's a blocks/formal_langs/db/install.xml file that it looks like is what's used to create the tables it needs, so I don't see why the table isn't getting created.
can you show this file? perhaps the query is odd or something or a typo... i can take a look at it...
It's in here: https://oasychev-moodle-plugins.googlecode.com/files/preg_231_release.zip Other plugins that come with Moodle also have an install.xml file that define their database tables, and they're in the same format (XMLDB).
Can you retest the installation, and first have the my.cnf add general_log_file=query.log and restart the service? this should log all queries and also the invalid ones, so we can see there what query gets sent and why it fails.
(In reply to AL13N from comment #27) > Can you retest the installation, and first have the my.cnf add > general_log_file=query.log and restart the service? > > this should log all queries and also the invalid ones, so we can see there > what query gets sent and why it fails. The query.log file doesn't get created.
Fedora has issued an advisory for this on May 20: http://lists.fedoraproject.org/pipermail/package-announce/2013-May/107026.html
URL: (none) => http://lwn.net/Vulnerabilities/552177/
do you have to pre-create it with the mysql user? also full path is safest. it needs to be in the [mysqld] section
oops, it seems you also need: general_log = 1
(In reply to AL13N from comment #30) > do you have to pre-create it with the mysql user? I don't know what that means. > also full path is safest. > > it needs to be in the [mysqld] section OK, corrected that. (In reply to AL13N from comment #31) > oops, it seems you also need: > > general_log = 1 Added that too. The log is generated now. I don't see it creating the table block_community (from one of the Moodle bundled plugins in blocks/community), which also has one of those install.xml files, either. In fact looking through some other install.xml files in other places, they're not all getting run. I don't know if it's just not getting to them because it's crapping out though. I don't know why "SELECT * FROM mdl_block_formal_langs WHERE visible = '1'" is getting run, where that's coming from, or why it's happening when install.xml hasn't created that table yet.
Created attachment 4079 [details] query.log
ok, so from the query it's obvious that this is a moodle bug, ie: the table gets used before it gets created (if it ever gets created) i was thinking there would be a failed query, which might have been due to mariadb, but i guess not :-) maybe talking with upstream developers would be nice...
I got a patch from the upstream developer of the plugin that fixes this. Sorry for all of the trouble! Advisory: ======================== Updated moodle package fix security vulnerabilities: The assignment module in Moodle before 2.4.4 was not checking capabilities for users downloading all assignments as a zip (CVE-2013-2079). The Gradebook's Overview report in Moodle before 2.4.4 was showing grade totals that may have incorrectly included hidden grades (CVE-2013-2080). When registering a site on a hub (not Moodle.net) site in Moodle before 2.4.4, information was being sent to the hub regardless of settings chosen (CVE-2013-2081). There was no check of permissions for viewing comments on blog posts in Moodle before 2.4.4 (CVE-2013-2082). Form elements named using a specific naming scheme were not being filtered correctly in Moodle before 2.4.4 (CVE-2013-2083). http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2080 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2081 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2082 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2083 https://moodle.org/mod/forum/discuss.php?d=228930 https://moodle.org/mod/forum/discuss.php?d=228931 https://moodle.org/mod/forum/discuss.php?d=228933 https://moodle.org/mod/forum/discuss.php?d=228934 https://moodle.org/mod/forum/discuss.php?d=228935 http://docs.moodle.org/dev/Moodle_2.4.4_release_notes https://moodle.org/mod/forum/discuss.php?d=228536 ======================== Updated packages in core/updates_testing: ======================== moodle-2.4.4-1.1.mga3 from moodle-2.4.4-1.1.mga3.src.rpm
Whiteboard: has_procedure feedback => has_procedure
Testing mga3 32 & 64
With the failed installation of the existing version in place before updating, moodle is unable to complete the installation. It gives a message about updating hte database but then gives an error when checking the environment. It seems to be expecting moodle 2.2.. moodle version 2.2 is required and you are running Check Everything else is green OK. Dropping all tables in moodle db and restarting the web based installation does now complete. I think this should have a README.update.urpmi though with info to drop the existing tables and restart the installation if they installed fresh from release.
Other than this it's ok mga3 32 & 64
I'm not gonna add a README.update.urpmi just for that. This package was just introduced a few weeks ago, and I doubt anyone's used it yet.
That's what they're for isn't it? Anyway, it's your decision. Validating. Advisory: ======================== Updated moodle package fix security vulnerabilities and correct an issue where web based installation would fail: The assignment module in Moodle before 2.4.4 was not checking capabilities for users downloading all assignments as a zip (CVE-2013-2079). The Gradebook's Overview report in Moodle before 2.4.4 was showing grade totals that may have incorrectly included hidden grades (CVE-2013-2080). When registering a site on a hub (not Moodle.net) site in Moodle before 2.4.4, information was being sent to the hub regardless of settings chosen (CVE-2013-2081). There was no check of permissions for viewing comments on blog posts in Moodle before 2.4.4 (CVE-2013-2082). Form elements named using a specific naming scheme were not being filtered correctly in Moodle before 2.4.4 (CVE-2013-2083). http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2080 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2081 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2082 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2083 https://moodle.org/mod/forum/discuss.php?d=228930 https://moodle.org/mod/forum/discuss.php?d=228931 https://moodle.org/mod/forum/discuss.php?d=228933 https://moodle.org/mod/forum/discuss.php?d=228934 https://moodle.org/mod/forum/discuss.php?d=228935 http://docs.moodle.org/dev/Moodle_2.4.4_release_notes https://moodle.org/mod/forum/discuss.php?d=228536 ======================== Updated packages in core/updates_testing: ======================== moodle-2.4.4-1.1.mga3 from moodle-2.4.4-1.1.mga3.src.rpm
Keywords: (none) => validated_updateWhiteboard: has_procedure => has_procedure mga3-32-ok mga3-64-okCC: (none) => sysadmin-bugs
Packages have been pushed to updates.
Status: NEW => RESOLVEDCC: (none) => boklmResolution: (none) => FIXED
CC: boklm => (none)