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: =dev-db/mariadb-10.0.27 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: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
# Official test instructions: # USE='embedded extraengine perl openssl static-libs' \ # FEATURES='test userpriv -usersandbox' \ # ebuild mariadb-10.0.27.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}"
amd64 stable
Stable on alpha.
Stable for HPPA PPC64.
arm stable
x86 stable
sparc stable
ppc stable
ia64 stable. Maintainer(s), please cleanup.
This issue was resolved and addressed in GLSA 201610-06 at https://security.gentoo.org/glsa/201610-06 by GLSA coordinator Aaron Bauman (b-man).
Reopening for cleanup. Please cleanup the following packages: =dev-db/mariadb-10.0.25 =dev-db/mariadb-10.0.26
Cleanup complete
(In reply to Brian Evans from comment #13) > Cleanup complete Thanks, Brian!
This issue was resolved and addressed in GLSA 201701-01 at https://security.gentoo.org/glsa/201701-01 by GLSA coordinator Thomas Deutschmann (whissi).
