Earlier MySQL used to read my.cnf from three locations, in that order: - /etc - datadir - $HOME/.my.cnf The second is particularly unsafe, because datadir is writable by the mysqld server, and a user that can connect to MySQL can create my.cnf in the datadir using SELECT ... OUTFILE. Over time various safety mechanisms were implemented: - mysqld no longer reads my.cnf in the datadir. Still, mysqld_safe.sh does and forces the server to, so if the server is started via mysqld_safe.sh, my.cnf in the datadir is still used. - --secure-file-priv command-line option limits SELECT ... OUTFILE to the specified directory, it's recommended to set it outside of datadir - SELECT ... OUTFILE creates files that are world-writable and mysqld refuses to read my.cnf if it is world-writable. But as was recently discovered by Dawid Golunski, one can abuse @@general_log_file variable to create a my.cnf in the datadir, and it will be not created world-writable, so the both mysqld_safe and mysqld will read it on startup.
Arches, please test and mark stable. The test suite should pass following the official instructions. Local timeouts may be expected on resource starved machines. (each test thread can spawn up to 4 server instances) Target keywords: =dev-db/mysql-5.6.33 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 # Official test instructions: # USE='embedded extraengine perl openssl static-libs' \ # FEATURES='test userpriv -usersandbox' \ # ebuild mysql-5.6.33.ebuild \ # digest clean package # Parallel testing is enabled, auto will try to detect number of cores # You may set this by hand. # The default maximum is 8 unless MTR_MAX_PARALLEL is increased export MTR_PARALLEL="${MTR_PARALLEL:-auto}"
Does 5.6.33 really fix this bug? The advisory explicitly says this is an affected version.
Based on our information this should have been addressed with 5.6.33. However when comparing Mysql's sql/sys_vars.cc file with MariaDB's fix (https://github.com/MariaDB/server/commit/470f2598cca350b79531bf0b88463a47d94abec3 and https://github.com/MariaDB/server/commit/0098d789c9d8be15d62230289f603ac8f3d5b275) it looks like it isn't So I am stopping stabilization request for the moment to wait for clarification from upstream..
OK, our information were correct. From MySQL 5.6.33 changelog (https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-33.html): > - For mysqld_safe, the argument to --malloc-lib now must be one of the > directories /usr/lib, /usr/lib64, /usr/lib/i386-linux-gnu, or > /usr/lib/x86_64-linux-gnu. In addition, the --mysqld and > --mysqld-version options can be used only on the command line and not > in an option file. (MySQL-Bug #24464380) > > - It was possible to write log files ending with .ini or .cnf that later > could be parsed as option files. The general query log and slow query > log can no longer be written to a file ending with .ini or .cnf. > (MySQL-Bug #24388753) > > - Privilege escalation was possible by exploiting the way REPAIR TABLE > used temporary files. (MySQL-Bug #24388746)
amd64 stable
Stable on alpha.
Stable for HPPA PPC64.
arm stable
x86 stable
sparc stable
ppc stable
ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Cleanup already done, see https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-db/mysql?id=4a70076de06492fdb818f2881ef7834ef11c0f17 @ Security: Please vote for GLSA.
Same as before. No voting required.
This issue was resolved and addressed in GLSA 201701-01 at https://security.gentoo.org/glsa/201701-01 by GLSA coordinator Thomas Deutschmann (whissi).