MySQL access privilegesIn this blog, I will provide answers to the Q & A for the Troubleshooting MySQL Access Privileges Issues webinar.

First, I want to thank everybody for attending the February 23 webinar. The recording and slides for the webinar are available here. Below is the list of your questions that I wasn’t able to answer during the webinar, with responses:

Q: Should the root@localhost user be given ALL privileges or Super privileges? Does All include Super privileges also?

A: Yes, you should have a user with all privileges. Better if this user has access from localhost only. ALL  includes SUPER.

Q: We have users who connect via a laptop that get dynamic IP addresses, so granting access with a server name is an easier way to manage these users. Can I grant access to a MySQL database with a hostname as opposed to an ipaddress? For example “[email protected]” as opposed to “[email protected]”?  Is the host cache/performance_schema required for this?

A: Yes, you can.

But it looks like I was not clear about host cache. Host cache is an internal structure that is always available and contains answers from DNS server. You cannot enable or disable it. Until version 5.6, you also could not control it. For example, if the cache got corrupted the only thing you could do is to restart the server. Version 5.6 the table HOST_CACHE was introduced to Performance Schema. With this table you can examine the content of the host cache and truncate it if needed.

Q: If there are multiple entries in the user table that match the connecting user (e.g., with wildcards, hostname, and IP), what rules does MySQL use to select which is used for authentication?  Does it try multiple ones until it gets a password match?

A: Not, mysqld does not try to hack your passwords. Instead it sorts the user table by name and host in descending order as I showed on slide #37 (page 110). Then it takes the first matching row. So if you created users foo@somehost, foo@some% and foo@1.2.3.4, and you connect as foo from somehost, mysqld first checks the user name and then chooses the first matching row foo@somehost. If you instead connect as foo from someotherhost, mysqld chooses  foo@some%. An IP-based host is chosen if either mysqld started with option skip-networking or if 1.2.3.4  points to a host whose name does not start with “some”.

Mixing IP-based and name-based hosts is dangerous in situations when the same host can be resolved as somehost or 1.2.3.4. In this case, if something goes wrong with the host cache or DNS server, the wrong entry from the user table can be chosen. For example, if you initially had three hosts: uniquehost (which resolves as 1.2.3.4), somehost (which resolves as 4.3.2.1) and someothershost (which resolves as 4.3.2.2). Now you decided to re-locate uniquehost to a machine with IP 1.2.3.5 and use IP 1.2.3.4 for the host with name someyetanotherhost. In this case, the clients from the machine with IP 1.2.3.4 will be treated as foo@some%, which isn’t what you want.

To demonstrate this issue, I created two users and granted two different privileges to them:

Now I modified my /etc/hosts  file and pointed address 192.168.0.4  to name Thinkie:

Now, if I connect as sveta both Thinkie and 192.168.0.4 are resolved to the same host:

Now I modified the  /etc/hosts  file and pointed Thinkie  back to 127.0.0.1  ( localhost):

But host 192.168.0.4 still resolves to Thinkie:

The reason for this is a stalled host cache, which can be easily observable with Performance Schema:

After I truncated table host_cache the numeric host resolves as I expect:

Q: What privileges are required for a non-root or non-super user to be to use mysqldump to dump the database and then restore it on a different server?

A: Generally you should have SELECT  privilege on all objects you are going to dump. If you are dumping views, you also should have SHOW VIEW  privilege in order to run SHOW CREATE TABLE. If you want to dump stored routines/events, you need access to them as well. If you use option --lock-tables or --lock-all-tables, you should have the  LOCK  privilege.

Q: If the max_connection value is reached in MySQL, can root@localhost with ALL privilege still login, or with Super privilege user can login?

A: ALL includes SUPER, so a user with ALL  privilege can login. Just note there can be only one such connection, thus do not grant SUPER  or ALL privilege to the application user.

Q: Is it possible to remove a priv at a lower level? In other words, grant select and delete at the database level, but remove delete for a specific table?  Or can privs only be added to?

A: Not, MySQL will reject such a statement:

Q: How can we have DB user roles… like a group of grants for a particular role?

A: You have several options.

  1. Use MariaDB 10.0.5 or newer. You can read about roles support in MariaDB here
  2. Use MySQL 8.0. You can read about roles in MySQL 8.0 here
  3. With MySQL 5.7: imitate roles as I showed on slide 19 (pages 53 – 60)
  4. With MySQL 5.5 and 5.6: use the same method as shown on slides, but use the custom authentication plugin that supports proxy users.
  5. Always: create a template with privileges, assign privileges to each user manually.

Q: How would you migrate role simulation with proxy users to actual roles in MySQL 8.x?

A: I would drop the proxied user and create a role with the same privileges instead, then grant the proxy user the newly created role instead of PROXY.

Q: Is there a plugin to integrate Active Directory and MySQL in order to use Active Directory groups?

A: There is commercial Windows Authentication Plugin, available in versions 5.5 and newer. You can also use the open source Percona PAM authentication plugin and connect it to Active Directory the same way as can be done for LDAP. There is a blog post describing how to do so, but I’ve never used this method myself.

Q: Can we use central auth with MySQL?

A: Yes, with the help of the PAM Plugin. There are tutorials for LDAP and Active Directory. You may use similar methods to setup other kinds of authentications, such as Kerberos.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Valeriy

Useful post, but let me add some minor comments:

“Version 5.6 the table HOST_CACHE was introduced…” should be rephrased like “In Version 5.6 the table HOST_CACHE was introduced…” or somehow else (native speakers can suggest better order of words). Also, FLUSH HOSTS was available well before 5.6, so you could control the content of cache in a sense that you could clean it up.

In the phrase “thus do not grant SUPER or ALL privilege to the application user.” I see “or ALL” highlighted, not just “ALL”.

0