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.
From https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/: > The way Percona increased security was by limiting which libraries are > allowed to be loaded with LD_PRELOAD (including --malloc-lib), and > limiting them to /usr/lib/, /usr/lib64 and the MySQL installation base > directory. > > This means only locations that are accessible by root users can load > shared libraries. > > The following Percona Server versions have this fix: > > 5.5.51-38.1 > 5.6.32-78.0 > 5.7.14-7
Vulnerable version removed from tree via > commit 0d92d10590a27e1814f60685bc3109d6cc4dea83 > Author: Thomas Deutschmann > Date: Wed Sep 14 02:58:43 2016 +0200 > > dev-db/percona-server: Drop old security vulnerable versions > > Gentoo-Bug: https://bugs.gentoo.org/593610 > > Package-Manager: portage-2.3.0
dev-db/percona-server - is not stable. Changing whiteboard, no glsa for non stable packages. Maintainer(s), Thank you for your work.
