mysql如何给用户分配执行权限_mysql执行权限设置

3次阅读

mysql中execute权限仅适用于调用存储过程、函数等可执行对象,不等同于sql执行权限;需显式授予select、insert等具体权限,且应遵循最小权限原则,避免all privileges。

mysql如何给用户分配执行权限_mysql执行权限设置

GRANT 语句必须指定具体权限和对象

MySQL 不支持笼统的“执行权限”概念,EXECUTE 权限只适用于存储过程、函数、触发器等可执行数据库对象,不是对 SQL 语句(如 SELECTINSERT)的统称。误以为 GRANT EXECUTE ON *.* 能让用户运行任意 SQL,会导致权限不足或越权错误。

常见错误现象:Error 1142 (42000): SELECT command denied to user,本质是没给 SELECT 权限,而非缺少 EXECUTE

  • EXECUTE 权限仅用于调用已存在的存储过程或函数:例如 GRANT EXECUTE ON PROCEDURE mydb.calc_total TO 'user1'@'localhost';
  • 想允许增删改查,必须显式授予 SELECTINSERTUPDATEdelete 等权限
  • 权限对象可以是数据库级(mydb.*)、表级(mydb.users)或列级(需在 GRANT 中列出列名)

CREATE ROUTINE 和 ALTER ROUTINE 是创建/修改存储过程的前提

即使给了 EXECUTE 权限,用户也无法自己创建存储过程——那需要额外的 CREATE ROUTINE 权限;修改已有过程则需要 ALTER ROUTINE。这两个权限常被忽略,导致 CREATE PROCEDURE 报错 ERROR 1227 (42000): access denied; you need (at least one of) the SUPER privilege(s)(MySQL 5.7+ 默认禁用 SUPER,改用细粒度权限)。

  • 授予创建权限:GRANT CREATE ROUTINE ON mydb.* TO 'dev'@'%';
  • 授予修改权限:GRANT ALTER ROUTINE ON mydb.* TO 'dev'@'%';
  • 这两个权限本身不赋予执行能力,仍需单独 GRANT EXECUTE

FLUSH PRIVILEGES 并非总是必要

使用 GRANTREVOKE 后,权限会立即生效(MySQL 5.7.6+ 默认行为),无需手动执行 FLUSH PRIVILEGES。只有在直接操作 mysql 系统库表(如 INSERT INTO mysql.user)后才需要刷新。

滥用 FLUSH PRIVILEGES 不但多余,还可能掩盖真实问题:比如权限未生效其实是由于主机名匹配失败('user'@'192.168.1.%' vs 'user'@'localhost'),而不是缓存没刷新。

  • 确认用户连接来源:SELECT USER(), CURRENT_USER(); —— 前者是客户端声明的身份,后者才是 MySQL 实际匹配到的账号
  • 检查账号是否存在且主机名精确匹配:SELECT Host, User FROM mysql.user WHERE User = 'xxx';
  • 修改权限后,新连接立即生效;已有连接的权限不变,需重连

最小权限原则下避免 ALL PRIVILEGES

GRANT ALL PRIVILEGES ON mydb.* TO 'app'@'10.0.2.%'; 看似方便,实则风险极高:它包含 DROPCREATE VIEWTRIGGER 等应用通常不需要的能力,一旦应用漏洞被利用,攻击面大幅扩大。

生产环境应严格按需授权。例如 Web 应用通常只需:

  • SELECT, INSERT, UPDATE, DELETE(禁止 DROPCREATE table
  • 如果调用存储过程,再加 EXECUTE,不加 CREATE ROUTINE
  • 明确限制主机范围,避免用 '%' 匹配所有地址

权限颗粒度越细,出问题时定位和回滚越快。别省那几行 GRANT 语句。

text=ZqhQzanResources