MySQL函数执行权限由EXECUTE权限控制,创建需CREATE ROUTINE和ALTER ROUTINE,且SQL SECURITY DEFINER机制可能导致提权风险。
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 除非必要;如必须用,定义者账号应是低权限专用账号(比如只拥有函数所需那几张表的权限)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 表(不推荐),就必须刷SELECT User, Host FROM mysql.user WHERE User = 'xxx';,注意 'user'@'localhost' 和 'user'@'127.0.0.1' 是不同账号GRANT EXECUTE ON FUNCTION mydb.MyFunc 和调用 mydb.myfunc() 会失败otherdb.my_func(),但权限只给了 mydb.my_func → 必须权限名与调用名完全一致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;
函数权限真正难控的点不在授权语句本身,而在于 SQL SECURITY DEFINER 的隐式权限继承和 binlog 对函数创建的静默拦截——这两处最容易在上线后暴露问题。