Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL)
-
None
Description
information_schema.check_constraints can leak unwanted information via check constraints definitions. For example, a user can infer column names from a table:
create user foo; |
|
create database db; |
use db; |
create table t1 (a int, b int, CONSTRAINT CHECK (b > 0)); |
insert into t1 values (1, 2), (2, 3); |
grant select (a) on t1 to foo; |
|
show grants for foo; |
|
select * from information_schema.check_constraints; |
|
CONNECT(con1,localhost, foo,, db); |
select a from t1; |
select * from information_schema.check_constraints; |
|
--CONNECTION DEFAULT;
|
|
drop database db; |
This will print, when logged in as user foo:
select * from information_schema.check_constraints; |
CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_NAME CHECK_CLAUSE
|
def db t1 CONSTRAINT_1 `b` > 0
|
So now, user foo knows table t1 has a `b` column.