In what order MySQL permissions are applied on database?

Question

I want to understand the priority of executing MySQL grants privileges.

For e.g.:

I want to grant two different types of privileges on a single db Demo.

1.GRANT SELECT ON Demo.table1 TO abc@123;

2.GRANT ALL PRIVILEGES ON Demo.* TO abc@123;

As per my assumption, no 2 grant will overwrite the limitations of no 1 grant, therefore, ends up giving access to all tables including table1 to abc user.

And if I want to give SELECT privilege for table1 then I should change the order of executing permissions so that they don't get overwritten by *.

I'm not sure if this is how MySQL manages such permissions. Anyone with a different opinion?

Thanks in advance.

Answer 1

According to MySQL 5.7 Documentation under Privileges Provided by MySQL

The privileges granted to a MySQL account determine which operations the account can perform. MySQL privileges differ in the contexts in which they apply and at different levels of operation:

• Administrative privileges enable users to manage operation of the MySQL server. These privileges are global because they are not specific to a particular database.

• Database privileges apply to a database and to all objects within it. These privileges can be granted for specific databases, or globally so that they apply to all databases.

• Privileges for database objects such as tables, indexes, views, and stored routines can be granted for specific objects within a database, for all objects of a given type within a database (for example, all tables in a database), or globally for all objects of a given type in all databases.

From this, the order is:

• Global Privileges
• Database Privileges
• Table Privileges

The tables that drive the order are:

• mysql.user
• mysql.db
• mysql.tables_priv
• mysql.columns_priv

With regard to an identical username @ host, please note what pages 486,487 state about mysql's authentication algorithm from MySQL 5.0 Certification Study Guide

There are two stages of client access control:

In the first stage, a client attempts to connect and the server either accepts or rejects the connection. For the attempt to succeed, some entry in the user table must match the host from which the client connects, the username, and the password.

In the second stage (which occurs only if a client has already connected sucessfully), the server checks every query it receives from the client to see whether the client has sufficient privileges to execute it.

The server matches a client against entries in the grant tables based on the host from which the client connects and the user the client provides. However, it's possible for more than one record to match:

Host values in grant tables may be specified as patterns contains wildcard values. If a grant table contains entries from myhost.example.com, %.example.com, %.com, and %, all of them match a client who connects from myhost.example.com.

Patterns are not allowed for the User values in grant table entries, but a username may be given as an empty string to specify an anonymous user. The empty string matches any username and thus effectively acts as a wildcard.

When the Host and the User values in more than one user table record match a client, the server must decide which one to use. It does this by sorting records with the most specific Host and User column values first, and choosing the matching record that occurs first in the sorted list, Sorting take place as follows:

In the Host Column, literal values such as localhost, 127.0.0.1, and myhost.example.com sort ahead of values such as %.example.com that have pattern characters in them. Pattern values are sorted according to how specific they are. For example, %.example.com is more specific than %.com, which is more specific than %.

In the User column, non-blank usernames sort ahead of blank usernames. That is, non-anonymous users sort ahead of anonymous users.

The server performs this sorting when it starts. It reads the grant tables into memory, sorts them, and uses the in-memory copies for access control.

When you look at these two perspectives, mysqld should always go top down when evaluating grants. Keep in mind that

• GRANT SELECT ON Demo.table1 TO abc@123; is stored in mysql.tables_priv
• GRANT ALL PRIVILEGES ON Demo.* TO abc@123; is stored in mysql.db
• For more information, please see my older post Unable to remove permission for mysql.user

AND THE OSCAR GOES TO ...

GRANT ALL PRIVILEGES ON Demo.* TO abc@123;