MySQL configuration file

[jlecour]

Hi,

I hope I'm not making a duplicate here.
I love this plugin and find it a clearly better replacement. I've been using it on Debian servers for years.

It recently appeared to my that putting the login/password of MySQL in the /etc/munin/plugin-conf.d/munin-node file is a possible security problem.

I didn't find a way to use a file like /etc/mysql/debian.cnf where all the credentials are stored, in a more secure way.
I've been using this configuration with other MySQL plugins and was surprised that it is not possible here.

Maybe it is, but I didn't find the documentation for it.

Help and/or comments about this will be appreciated. Thanks.

[meersjo]

While I agree that it is mildly sloppy to have multiple files with the credentials, both live under /etc, I don't really see a major difference in security. Nothing stops you from setting the file 0400 for the munin user.

[jlecour]

The munin user can read the configuration file, but not the external file. That is the problem setting 0400 won't help fix.

If there is ever a security bug in the not-run-by-root portion of Munin, the database password can be read. In the external file (here /etc/mysql/debian.cnf) Munin can read it wut the munin user can.

[meersjo]

The plugin is never root, it is immediately started under user munin. Thus, if the munin user cannot read the external authentication file, then neither can the plugin code.

However, a better solution for the issue you are reporting would be support for the .mylogin.cnf encrypted credential store generated by mysql_config_editor. As the plugin uses DBD/DBI, however, that is not something that should be implemented here - it is something that needs to be added at the lower level.

[aj-gh]

MySQL credential security was also a topic I was looking into recently.
I approached this topic on two sides:

• Configuration file security
• Restrictive MySQL account privileges

Configuration file security:
While the "mysql.conf" configuration file dropped into /etc/munin/plugin-conf.d by this package is readable by everyone by default it's sufficient to be readable by the user running the main munin-node process. It might be good to mention this somewhere or even adjust the installation routines.

Restrictive MySQL permissions:
I don't know why most guides seem to suggest using the MySQL "root" user (!) or to give some other user full select access to the "mysql" database while it seems to be only used as the initial database for the MySQL connect, so giving access to any table seems fine.
It seems to be sufficient to grant the following privileges. You could even use a separate monitoring-only database (only SELECT access required), but the statements below work with last effort:

GRANT PROCESS, REPLICATION CLIENT ON . TO 'monitoringuser'@'localhost' IDENTIFIED BY 'yourpassword';
GRANT SELECT ON mysql.time_zone TO 'monitoringuser'@'localhost';

Note: There seem to be some recommendations to grant the "SUPER" privilege. Is this still necessary? If so, for which graphs?
I would strongly suggest to document the required privileges on a least-privileges-that-work basis in the main documentation or faq section.

This seems to work for me but as usual I welcome any suggestions or further improvements.

[jlecour]

In fact, I git it to work without repeating the password, like this :

[mysql*]
user root
env.mysqlopts --defaults-file=/etc/mysql/debian.cnf
env.mysqluser debian-sys-maint
env.mysqlconnection DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf

NB : it's a Debian server, so settings may vary with your own OS.

[szepeviktor]

I was also considering /etc/mysql/debian.cnf but is highly insecure, it has all privileges.
Using a can't-do-anything user is much better.