Observed that some passwords for mysql user running Grafana are not accepted when accessed from the config file upon start up. But the same passwords work when manually logging into mysql as the user. Appears to be issues with how Grafana processes certain password upon starting. Particularly, passwords with special characters like # cause problems.
Hi @wkneewalden ,
I know this is a security issue, but could you share your datasource config file on startup and an example of a password that’s not working in the config, but works manually. Make any security edits needed. And do you mean that manually entering credentials in Grafana’s datasource setup UI will make it work, or are you referring to a more direct method of manually accessing the db, like using
curl or a local login?
what are you deploying to?
what grafana version?
what mysql version/any unusual configs?
is the mysql instance remote? Any reverse proxy/services in front of it?
Thanks for the response. This was observed during a deployment in Oct 2020, and now going back to investigate. Might have to retest with latest Grafana version to see if issue still occurs.
At the time the version of Grafana was 7.1.5. The mysql version was 5.7.12. In terms of configuration, nothing unusual with mysql. The endpoint is an RDS server for Grafana hosted on AWS, hence for Grafana the config file grafana.ini includes the following (with generic values here):
type = mysql
host = RDS_ENDPOINT:DB_PORT
name = DB_NAME
user = DB_USER
password = rds_pass
The password attempted that did not work was rds_pass=7yX4reG#zXW8Bk. What is observed is that when this password is put in the grafana.ini and Grafana server attempts to start, the user cannot login to mysql of the RDS with the password. However, by using mysql in the terminal of the instance running the server and manually logging into the user, the password works.
The work around going forward has been to test all password formats in the testing environment first to see if they work with grafana.ini before using one in production. But understanding what in the format caused the issue would be helpful.
My immediate impression on seeing that password is that the # character has
been interpreted as the start of a comment, and therefore Grafana thinks the
password is 7yX4reG.
Ok, thanks. If I see any other passwords through testing that give same result, I will post some output from Grafana log. Unfortunately, I don’t have the log from this first password example since it happened a while ago. But fairly certain the log gave a message indicating user cannot log into mysql server. Other special characters have not caused issues. That would fit with the above comment.