您的位置:首页 > 数据库 > MySQL

[MySQL] 存储过程、函数、触发器和视图的权限检查

2013-10-18 09:14 841 查看
当存储过程、函数、触发器和视图创建后,不单单创建者要执行,其它用户也可能需要执行,换句话说,执行者有可能不是创建者本身,那么在执行存储过程时,MySQL是如何做权限检查的?

在默认情况下,MySQL将检查创建者的权限。假设用户A创建了存储过程p()访问表T,并把execute的权限赋给了B,即使用户B没有访问表T的权限,也能够通过执行存储过程p()访问表T。

下面看一个例子:

首先,我们创建一个表test.t和两个用户a,b,并把权限赋予用户a

root@(none) 05:39:45>create table portal.t as select * from mysql.user;
Query OK, 25 rows affected (0.16 sec)
Records: 25  Duplicates: 0  Warnings: 0

root@(none) 05:39:55>create user a identified by 'a';
Query OK, 0 rows affected (0.02 sec)

root@(none) 05:40:51>create user b identified by 'b';
Query OK, 0 rows affected (0.00 sec)

root@(none) 05:40:59>grant all privileges on portal.* to a;
Query OK, 0 rows affected (0.01 sec)

接着,以用户a创建存储过程p():

DELIMITER $$
USE portal$$
CREATE PROCEDURE `p`()
BEGIN
SELECT COUNT(*) FROM portal.t;
END$$
DELIMITER ;

并把执行该存储过程的权限赋给用户b:

root@(none) 05:54:28>grant execute on procedure portal.p to b;
Query OK, 0 rows affected (0.00 sec)

这时候,已用户b连接后通过执行存储过程可以获得t表的访问权限:

b@(none) 05:58:20>call portal.p();
+----------+
| COUNT(*) |
+----------+
|       25 |
+----------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

但如果直接访问将出现权限错误:

b@(none) 05:58:40>select count(*) from portal.t;
ERROR 1142 (42000): SELECT command denied to user 'b'@'192.168.1.15' for table 't'


MySQL这样的设置有一定的道理,但同时也带来了安全隐患:比如如果一个用户通过创建一个存储过程来访问敏感数据,则可以调用该存储过程的所有用户都能访问敏感数据。

如果你不想使用MySQL的默认设置,可以在定义存储程序和视图时在create语句里使用definer = account字句指定定义者,这样在执行存储程序和视图时,将检查definer的权限,而不是创建者的权限。

举个例子,当你用root 创建一个存储过程时,在默认情况下,在执行该存储过程时,执行者将获得root的权限,但当你加上definer = A后,执行者只能获得A的权限。

但是definer还是没能完全解决上面提到的安全隐患,别急,MySQL还提供了SQL SECURITY选项来控制权限,它有两个取值:

1)DEFINER:以定义者的权限执行(默认)

2)INVOKER:以调用者的权限执行

如果你不想在存储程序或试图在执行时的权限多于调用者,就设置SQL SECURITY INVOKER即可。

例如,下面的试图将访问mysql.user,并设置了SQL SECURITY INVOKER选项,这样如果调用者没有访问mysql.user的权限,则无法通过权限检查。

create sql security invoker view v
as select * from mysql.user;

注意:因为触发器和事件是由系统调用的,没有调用者的概念,所以它们没有SQL SECURITY选项。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息