MySQL5.7 为什么移除了 test 库

MySQL的test库是个有趣的database,不仅仅是因为他的name.

1.test的权限很轻
在实例中,任何一个具有usage权限的用户,对test库下的表都有insert权限;可以用来存放监控,心跳,或者通过init_connect设定访问记录等。

避免了重复授权的麻烦,将acesslog单独放在test下即可。(需要留意,init_connect中的语句如果执行失败,连接就无法建立,这是个很不好的特性…,所以要确保test库下被依赖的表存在)

2.test库的权限如何定义
很多时候,在mysql.user表中,是看不到任何与test相关的权限,但读写确实正常的,这是为啥呢?

原因就在于mysql.db这个表设定了test的全局权限,as follow

select * from mysql.db\G

zabbix@127.0.0.1 [(none)]>select * from mysql.db\G

1. row

             Host: %

               Db: test

             User:

      Select_priv: Y

      Insert_priv: Y

      Update_priv: Y

      Delete_priv: Y

      Create_priv: Y

        Drop_priv: Y

       Grant_priv: N

  References_priv: Y

       Index_priv: Y

       Alter_priv: Y

Create_tmp_table_priv: Y

 Lock_tables_priv: Y

 Create_view_priv: Y

   Show_view_priv: Y

Create_routine_priv: Y

Alter_routine_priv: N

     Execute_priv: N

       Event_priv: Y

     Trigger_priv: Y

2. row

             Host: %

               Db: test\_%

             User:

      Select_priv: Y

      Insert_priv: Y

      Update_priv: Y

      Delete_priv: Y

      Create_priv: Y

        Drop_priv: Y

       Grant_priv: N

  References_priv: Y

       Index_priv: Y

       Alter_priv: Y

Create_tmp_table_priv: Y

 Lock_tables_priv: Y

 Create_view_priv: Y

   Show_view_priv: Y

Create_routine_priv: Y

Alter_routine_priv: N

     Execute_priv: N

       Event_priv: Y

     Trigger_priv: Y

如果要改变test库的权限,需要手工修改这个表,而不是处理mysql.user

3.test库的权限覆盖
如果想对特定用户回收test库权限,而不影响其他用户,只需要在mysql.db里面写入该用户专条数据即可

4.test库的风险
MySQL5.6安装数据库后默认就有test库,并且对所有用户开放读写权限,不单只test库,test_%库也拥有读写权限。

测试如下:

测试用zabbix账号,可以看到show grants是看不到test的任何权限的,另外test的权限不在mysql.user,而在mysql.db,切记!

zabbix@127.0.0.1 [(none)]>show grants for zabbix;

+-------------------------------------------------------------------------------------------------------------------------------------+

| Grants for zabbix@% |

+-------------------------------------------------------------------------------------------------------------------------------------+

| GRANT SELECT, PROCESS, REPLICATION CLIENT ON . TO 'zabbix'@'%' IDENTIFIED BY PASSWORD '*DEEF4D7D88CD046ECA02A80393B7780A63E7E789' |

| GRANT INSERT, UPDATE, DELETE, CREATE, DROP ON jishu8cc.* TO 'zabbix'@'%' |

+-------------------------------------------------------------------------------------------------------------------------------------+

以为直接删除test库,就可以解决权限问题吗?太天真了。说了,权限在mysql.db!

zabbix@127.0.0.1 [(none)]>drop database test;

Query OK, 0 rows affected (0.10 sec)

zabbix@127.0.0.1 [(none)]>create database test;

Query OK, 1 row affected (0.01 sec)

zabbix@127.0.0.1 [(none)]>use test;

Database changed

zabbix@127.0.0.1 [test]>create table t( a int );

Query OK, 0 rows affected (0.16 sec)

zabbix@127.0.0.1 [test]>insert into t value(1);

Query OK, 1 row affected (0.02 sec)

test_%库也是风险满满

zabbix@127.0.0.1 [(none)]>create database test1;

ERROR 1044 (42000): Access denied for user 'zabbix'@'%' to database 'test1'

zabbix@127.0.0.1 [(none)]>create database test_1;

Query OK, 1 row affected (0.00 sec)

zabbix@127.0.0.1 [(none)]>create database test_2;

Query OK, 1 row affected (0.00 sec)

zabbix@127.0.0.1 [(none)]>use test_1;

Database changed

zabbix@127.0.0.1 [test_1]>create table t( a int );

Query OK, 0 rows affected (0.16 sec)

zabbix@127.0.0.1 [test_1]>insert into t value(1);

Query OK, 1 row affected (0.02 sec)

测试的时候使用的是zabbix用户,实际你用任意低权限用户均对test库有读写权限,真是满满的风险。我不说黑客sql注入的问题了,我就想说没有控制好权限,别人拿你的test库玩,数据库磁盘写满了咋办?及时背锅么。。

鉴于这些,MySQL5.7安装时默认移除了test库,要权限自己添加呗!

5.总结
虽然test库方便了一些操作,例如第三方的mysql存活探测,但增加了安全风险,得不偿失,MySQL5.7才是王道,默认帮你想好安全问题。

是了,简单的MySQL存活探测,可以采用select 1+1; 高级的探测,请自行授权。

参考: http://f.dataguru.cn/thread-467473-1-1.html

来源

gaodevops