【问题标题】:Command denied for table 'session_variables'表“session_variables”的命令被拒绝
【发布时间】:2015-08-17 14:59:05
【问题描述】:

在更新 mysql 5.7.8-rc-log 版本后,我授予了这样的权限:

GRANT select ON test_db.* TO 'test'@'host';

并得到以下错误:

SELECT 命令拒绝用户 'test'@'host' 用于表 'session_variables'

但是当我授予这样的权限时:

GRANT select ON *.* TO 'test'@'host';

它有效。有人可以帮忙吗?

【问题讨论】:

  • 那么问题出在哪里? “我无法打开这扇上锁的门,但我打开它时它打开了”?呃,不是吗?
  • 我认为你的复制粘贴搞砸了,请检查你的帖子
  • 我不想为每个用户授予对所有数据库的访问权限——这就是问题所在。
  • 您的 GRANT 语法似乎相同,它们有何不同?
  • 我的错误,对不起。 GRANT select ON test_db.*GRANT select ON *.*

标签: mysql sql tsql privileges sql-grant


【解决方案1】:

这里是与此问题相关的article1article2article3。 根据这些文章,解决方法是在/etc/my.cnf 中设置show_compatibility_56 = on 并重新启动mysql 服务器。

MySQL 5.7 对我们查询全局变量和状态变量的方式进行了更改:INFORMATION_SCHEMA.(GLOBAL|SESSION)_(VARIABLES|STATUS) 表现在已弃用且为空。相反,我们将使用各自的 performance_schema.(global|session)_(variables|status) 表。

但变化不止于此;还有一个安全变化。

所以非root用户得到:

mysql> show session variables like 'tx_isolation';
ERROR 1142 (42000): SELECT command denied to user 'normal_user'@'my_host' for table 'session_variables'

解决方案?

以下是解决方案,但并非真正解决问题:

  • 显示命令。 SHOW GLOBAL|SESSION VARIABLES|STATUS 将正常工作,并且会隐式知道是否通过 information_schema 或 performance_schema 表提供结果。 但是,我们不应该对 SELECT 查询更满意吗?所以我真的可以做比 LIKE 'variable_name%' 更聪明的事情吗? 当然,您不能在服务器端游标中使用 SHOW。您存储的例程现在一团糟。 这并不能解决 GRANT 问题。
  • show_compatibility_56:5.7 中引入的变量,布尔值。在多个方面,这确实是一部变相的时间旅行悖论小说。 文档介绍了它,并说它已被弃用。 时间旅行悖论:O 但它实际上适用于 5.7.8(最新) 时间旅行悖论情节变厚 你的自动化脚本事先并不知道你的 MySQL 是否有这个变量 因此 SELECT @@global.show_compatibility_56 将在 5.6 上产生错误 但是 SHOW GLOBAL VARIABLES LIKE 'show_compatibility_56' 的“安全”方式将因 5.7 上的权限错误而失败 时间旅行悖论:O 实际上,我的同事 Simon J. Mudd 建议,show_compatibility_56 默认为 OFF。我支持这种思路。否则它又是 old_passwords=1 。 show_compatibility_56 不能解决 GRANTs 问题。 这并不能解决任何迁移路径。它只是推迟了我遇到同样问题的那一刻。当我将变量从“1”翻转到“0”时,我又回到了第一格。

建议

我声称安全不是问题,如上所述。我声称如果当前的解决方案没有改变,Oracle 将在 5.6 中再次陷入 no-easy-way-to-migrate-to-GTID 的陷阱。我声称一次发生了太多变化。因此,我建议选择两种流程之一:

  • 流程 1:保留 information_schema,稍后迁移到 performance_schema 在 5.7 中,information_schema 表仍应生成数据。 对 information_schema 没有安全限制 从 information_schema 读取时生成警告(“......这将被弃用......”) performance_schema 也可用。有安全限制,无论如何。 在 5.8 中删除 information_schema 表;我们只剩下 performance_schema。
  • 流程 2:轻松迁移到 performance_schema: 在 5.7 中,performance_schema 表不需要任何特殊权限。任何用户都可以从中读取。 保持 show_compatibility_56 不变。 SHOW 命令自行在 information_schema 或 performance_schema 之间进行选择——就像现在所做的那样。 在 5.8 中,performance_schema 表将需要 SELECT 权限。

希望这会对你有所帮助。

【讨论】:

  • 我将 /etc/my.cnf 放入 [mysqld] 部分:show_compatibility_56=1,它解决了我的问题!谢谢@HaveNoDisplayName
  • 根据the mysql bug report关于此事的说法,似乎推荐的(??)解决此问题的方法是将master上的SELECT权限授予复制用户,例如:@987654331 @
【解决方案2】:

试试这个,它对我有用:

GRANT SELECT ON performance_schema.session_variables 到 stevejobs; GRANT SELECT ON performance_schema.session_status TO stevejobs;

【讨论】:

  • 请通过添加 4 空格缩进将您的代码格式化为代码
【解决方案3】:

试试下面的方法,也许你会得到结果。

GRANT ALL PRIVILEGES ON bedgeaj_medmax.transactions to 'bedgeaj_root'@'%'  IDENTIFIED BY 'password';

(或)

GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'%' WITH GRANT OPTION;

【讨论】:

  • 作为 root 我有授权选项,所以这不是解决方案。
【解决方案4】:

要访问 GLOBAL|SESSION VARIABLES,请尝试在 MYSQL 中使用命令:-

$ GRANT ALL ON sonar.* TO 'sonar'@'%' IDENTIFIED BY 'sonar';

$ GRANT ALL ON sonar.* TO 'sonar'@'localhost' IDENTIFIED BY 'sonar';

如果它不起作用,那么你应该尝试(它只为所有数据库的“声纳”用户提供 SELECT 权限):

$ GRANT SELECT ON *.* TO 'sonar'@'%' IDENTIFIED BY 'sonar';

$ GRANT SELECT ON *.* TO 'sonar'@'localhost' IDENTIFIED BY 'sonar';

它允许声纳用户访问所有具有 SELECT、INSERT、UPDATE、DELETE 权限的所有数据库(数据库上所有可能的移动。

$ GRANT ALL ON *.* TO 'sonar'@'%' IDENTIFIED BY 'sonar';

$ GRANT ALL ON *.* TO 'sonar'@'localhost' IDENTIFIED BY 'sonar';

【讨论】:

  • 这不是我的反对意见,但你知道通配符有多危险吗?即使操作人员有他们,您也应该告知他们危险
  • @Drew 已经在粗体标题中提到“它允许声纳用户访问所有具有 SELECT、INSERT、UPDATE、DELETE 权限的所有数据库(数据库上所有可能的移动)”我认为选择或不访问特定用户名很容易。
  • 我的错。由于眼睛疲劳,我的屏幕布局颜色反转。谢谢。我想每天最多审查 500 条就可以了
猜你喜欢
  • 2016-01-21
  • 1970-01-01
  • 2019-01-12
  • 1970-01-01
  • 2023-01-26
  • 2021-01-26
  • 2014-05-29
  • 2016-09-26
  • 2012-05-01
相关资源
最近更新 更多