mysql函数权限如何控制_mysql安全设置说明

MySQL函数执行权限由EXECUTE权限控制，创建需CREATE ROUTINE和ALTER ROUTINE，且SQL SECURITY DEFINER机制可能导致提权风险。

mysql函数权限如何控制_mysql安全设置说明第1张

MySQL 函数执行权限由哪些权限控制

MySQL 中函数的调用（EXECUTE）和创建（CREATE ROUTINE）是分离的，不能靠 SELECT 或 USAGE 权限代替。用户要能调用自定义函数，必须显式授予 EXECUTE 权限；要能创建函数，还需 CREATE ROUTINE 和 ALTER ROUTINE（修改时用），且全局 super_priv 或 system_variables_admin（8.0.16+）可能影响函数内访问系统变量的行为。

EXECUTE 权限可按数据库级（db_name.*）或函数级（db_name.func_name）授予，后者更精细
仅授予 SELECT 权限给函数所属数据库，**不会**自动允许调用该函数
函数体中若含 SQL SECURITY DEFINER（默认），则执行时以定义者权限检查，而非调用者——这是提权风险点

如何安全地授予函数调用权限（避免越权）

最常用也最可控的方式是按函数粒度授权，而不是开放整个数据库的 EXECUTE：

GRANT EXECUTE ON FUNCTION mydb.calc_discount TO 'app_user'@'10.20.30.%';

如果函数依赖特定表读写，还要同步确认调用者是否具备对应表的 SELECT/INSERT 等权限——函数内部的 SQL 仍受这些权限约束。

禁止对生产账号授予 GRANT OPTION，否则可能被用来扩散 EXECUTE 权限
避免使用 SQL SECURITY DEFINER 除非必要；如必须用，定义者账号应是低权限专用账号（比如只拥有函数所需那几张表的权限）

MySQL 8.0+ 可结合角色（ROLE）统一管理函数权限，例如：

CREATE ROLE func_reader;
GRANT EXECUTE ON FUNCTION mydb.get_user_status TO func_reader;
GRANT func_reader TO 'api_worker'@'%';

常见权限失效场景与排查方法

即使执行了 GRANT，调用函数仍报 ERROR 1370 (42000): execute command denied，多数是因为以下原因：

未执行 FLUSH PRIVILEGES; —— 一般不需要，但如果你直接改了 mysql.proc 表（不推荐），就必须刷
用户名或 host 不匹配：检查 SELECT User, Host FROM mysql.user WHERE User = 'xxx';，注意 'user'@'localhost' 和 'user'@'127.0.0.1' 是不同账号
函数名大小写敏感：Linux 下函数名区分大小写，GRANT EXECUTE ON FUNCTION mydb.MyFunc 和调用 mydb.myfunc() 会失败
函数属于另一个数据库但没指定库名：调用时写成 otherdb.my_func()，但权限只给了 mydb.my_func → 必须权限名与调用名完全一致

函数权限与安全模式（sql_mode）的隐性关联

MySQL 启用 NO_AUTO_CREATE_USER（已弃用）或严格模式本身不影响函数权限，但一个关键限制常被忽略：当 log_bin = ON（即开启 binlog）时，函数若含非确定性操作（如 NOW()、UUID()、子查询等），默认不允许创建，除非显式声明 DETERMINISTIC 或设置 sql_log_bin = OFF（不推荐）。这不是权限问题，但会导致 CREATE FUNCTION 失败，让人误以为是权限不足。

检查当前限制：
```
SELECT @@log_bin, @@sql_mode;
```

创建确定性函数示例：

CREATE DEFINER = 'admin'@'%' FUNCTION mydb.add_tax(price DECIMAL(10,2))
RETURNS DECIMAL(10,2)
READS SQL DATA
DETERMINISTIC
BEGIN RETURN price * 1.08; END;