MySQL Bugs: #94395: unauthenticated user can access db

Bug #94395	unauthenticated user can access db
Submitted:	19 Feb 2019 16:38	Modified:	20 Feb 2019 9:42
Reporter:	ding qi	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Security: Privileges	Severity:	S3 (Non-critical)
Version:	5.x	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	DB, grant, revoke, unauthenticated, user

Description:
An user can access db after the privilege is revoked.

------- case one ----
session A
connect(root,)
create user 'test'@'%' identified by '123456';
grant all privileges on gt.* to 'test'@'%';
create database gt;

session B
connect(test,123456)  
use gt;   //use db here

session A
revoke all privileges  on gt.* from 'test'@'%';

session B
create table  t(c int); //Query OK  --- The point
------- case one end----

It is because the two lines  inside the "check_access" function, 
"
 924   db_access= (db_access | sctx->master_access());
 925   *save_priv|= db_access;
"
they make this session held privileges of the current_db that saved when this session entered this db.

BUT, what makes confusion is the "case two" as follow, when I add session C as a contrast

------- case one ----
session A
connect(root,)
create user 'test'@'%' identified by '123456';
grant all privileges on gt.* to 'test'@'%';
create database gt;

session B
connect(test,123456)  
use gt;   //use db here

session C
connect(test,123456)  
use test;   //use test, but not gt

session A
revoke all privileges  on gt.* from 'test'@'%';

session B
create table  t(c int); //Query OK
session C
create table  gt.t2(c int); //Access Deny
------- case two end----

The create statements of session B and session C are doing the same thing in fact, but get different results.

How to repeat:
As above

Suggested fix:
In fact, I am afraid there are some other purpose about this design. 
So do not have a real suggestion :)

The document already described this: 
 https://dev.mysql.com/doc/refman/5.7/en/privilege-changes.html

Table and column privilege changes take effect with the client's next request.

Database privilege changes take effect the next time the client executes a USE db_name statement.

To Zhai， got it.

But the actions  in Session B and Session C in the case two , do confuse .

Why not check db access for every  query?  I looks more reasonable

Hello xiaobin lin,

Thank you for the report.
As Zhai rightly pointed, this is known and documented behavior in https://dev.mysql.com/doc/refman/5.7/en/privilege-changes.html

regards,
Umesh