mysql权限配置常见错误有哪些_mysql安全避坑指南

2次阅读

mysql中grant需加with grant option才允许转授权限,且该选项须随其他权限一并回收;localhost与127.0.0.1权限互不兼容;直接改表需flush privileges,而dcl语句自动生效;误删root@localhost将导致无法本地登录。

mysql权限配置常见错误有哪些_mysql安全避坑指南

GRANT 语句没加 WITH GRANT OPTION 却想授权给别人

很多人执行 GRANT select ON db.* TO 'user'@'%' 后,发现这个 user 自己能连上,但无法把权限再转授给其他人——这很正常,因为 MySQL 默认不开启代理授权能力。只有显式加上 WITH GRANT OPTION,该用户才拥有“授予权限的权限”。但要注意:WITH GRANT OPTION 本身不是独立权限,不能单独回收,只能随同其他权限一起用 REVOKE 撤销。

  • 错误写法:GRANT SELECT ON db.* TO 'a'@'%' ; → a 无法再 GRANT 给 b
  • 正确写法:GRANT SELECT ON db.* TO 'a'@'%' WITH GRANT OPTION;
  • 隐患:一旦授予,a 就可能绕过 dba 控制链,尤其在多租户场景下容易失控

localhost 和 127.0.0.1 被当成两个不同 host 导致权限不生效

MySQL 的权限系统严格区分 'user'@'localhost''user'@'127.0.0.1',哪怕你本地用 mysql 客户端连 127.0.0.1,匹配的也是后者,前者只响应 unix socket 连接(即不走 TCP)。很多同学配完 'user'@'localhost' 权限后,在命令行用 mysql -h 127.0.0.1 -u user 死活连不上,就是卡在这儿。

  • 验证方式:SELECT USER(), CURRENT_USER(); —— 前者是客户端声明的身份,后者才是实际匹配的权限账户
  • 安全建议:如无特殊需求,统一用 'user'@'127.0.0.1' 或更严格的内网 IP 段,避免 'user'@'%'
  • 注意:localhost 是个特殊标记,不会被 DNS 解析,也不走网络;而 127.0.0.1 是标准 IPv4 地址,强制走 TCP

FLUSH PRIVILEGES 忘了执行或执行了也没用

直接改 mysql.user 表(比如用 UPDATE)后,必须执行 FLUSH PRIVILEGES; 才能让内存中的权限缓存刷新;但如果你是用 GRANT/CREATE USER 等 DCL 语句操作的,MySQL 会自动重载,此时再执行 FLUSH PRIVILEGES; 不仅多余,还可能掩盖误操作——比如你本想删用户却手抖写了 GRANT,又立刻 FLUSH,反而让错误权限立即生效。

  • 需要手动 FLUSH 的场景:直连 mysql 库、UPDATE/INSERT/delete 权限表
  • 不需要 FLUSH 的场景:GRANTREVOKEDROP USERALTER USER
  • 典型误操作:UPDATE mysql.user SET authentication_string=... WHERE User='x'; FLUSH PRIVILEGES; → 密码字段名在 5.7+ 是 authentication_string,8.0+ 又改回 password?错,8.0 已移除 password 字段,必须用 ALTER USER

root@localhost 被禁用远程登录后,误删本地登录入口

有些运维为了“加固”,执行 DROP USER 'root'@'localhost';DELETE FROM mysql.user WHERE User='root' AND Host='localhost';,结果本地 sudo mysql 也登不进去了。MySQL 启动时如果找不到任何 root@localhost(且未启用 --skip-grant-tables),就真进不去了。

  • 恢复手段极麻烦:需停库、加 --skip-grant-tables 启动、手工 INSERT 回 root 用户、再重启
  • 安全替代方案:保留 'root'@'localhost',仅限制其只能从本地 socket 登录;对远程管理,新建专用账号并限定 IP 段,如 'admin'@'192.168.10.%'
  • 关键点:MySQL 5.7+ 默认 root 只有 'root'@'localhost',没有 'root'@'%',别一上来就 DROP

权限模型看着简单,但 host 匹配顺序、大小写敏感性、密码插件差异(caching_sha2_password vs mysql_native_password)、甚至 SQL_MODE 都会影响最终行为。最稳妥的做法是:所有权限变更走 GRANT/REVOKE,不用直接改表;所有用户 host 尽量写具体值,别贪图方便用 %;每次改完用 SHOW GRANTS for ... 确认实际生效内容。

text=ZqhQzanResources