[MDEV-17945] mysql.db contains ghost users which allow some operations on them Created: 2018-12-09  Updated: 2018-12-11  Resolved: 2018-12-11

Status: Closed
Project: MariaDB Server
Component/s: Authentication and Privilege System
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

Anonymous users have been removed:

MariaDB [test]> select user, host from mysql.user;
+------+-----------+
| user | host      |
+------+-----------+
| root | 127.0.0.1 |
| root | ::1       |
| root | localhost |
| root | ws        |
+------+-----------+
4 rows in set (0.00 sec)

and the server knows they don't exist:

MariaDB [test]> set password for '' = password('test');
ERROR 1133 (28000): Can't find any matching row in the user table

but RENAME or DROP still works:

MariaDB [test]> rename user '' to foo;
Query OK, 0 rows affected (0.03 sec)

nothing of course appears in mysql.user:

MariaDB [test]> select user, host from mysql.user;
+------+-----------+
| user | host      |
+------+-----------+
| root | 127.0.0.1 |
| root | ::1       |
| root | localhost |
| root | ws        |
+------+-----------+
4 rows in set (0.00 sec)

It happens because there is some contents in mysql.db (and it remains there even when anonymous users get dropped):

before RENAME

MariaDB [test]> select user, host from mysql.db;
+------+------+
| user | host |
+------+------+
|      | %    |
|      | %    |
+------+------+
2 rows in set (0.00 sec)

after RENAME

MariaDB [test]> select user, host from mysql.db;
+------+------+
| user | host |
+------+------+
| foo  | %    |
| foo  | %    |
+------+------+
2 rows in set (0.00 sec)

Now we can work the same way on user foo, etc.

It appears strange. I suppose it was meant to be so once, but I'm not sure it still is.



 Comments   
Comment by Sergei Golubchik [ 2018-12-11 ]

Yes, it's intentional. The structure of mysql.* privilege tables predates GRANT statement and it supports privilege configurations that cannot be created with GRANT/REVOKE or shown with SHOW GRANTS. They can be only created with INSERT/UPDATE/DELETE statements.

And such a configuration was a default one in a newly installed server since before GRANT was implemented.

It would be good to refactor privilege tables to support GRANT privilege model only, but the current behavior is definitely not a bug.

Generated at Thu Feb 08 08:40:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.