MySQL“针对表拒绝用户的命令”错误和用户权限

MySQL“针对表拒绝用户的命令”错误和用户权限,mysql,case-sensitive,bitnami,Mysql,Case Sensitive,Bitnami,当我运行以下命令时: SELECT p.*, (SELECT i.image FROM pimage i WHERE p.id = i.pid ORDER BY i.id ASC LIMIT 1 ) as image FROM products p WHERE p.categories LIKE '%$subCatId%' ORDER BY p.id ASC 在具有以下表的数据库上: pImage products sidebar specs

当我运行以下命令时:

SELECT p.*,
   (SELECT i.image
    FROM pimage i
    WHERE p.id = i.pid 
    ORDER BY i.id ASC
    LIMIT 1
   ) as image
FROM  products p
WHERE p.categories LIKE '%$subCatId%'
ORDER BY p.id ASC
在具有以下表的数据库上:

pImage
products
sidebar
specs
我得到一个错误:

1142-为表“pimage”选择拒绝用户“database_user”@“localhost”的命令

不幸的是,今天下午在我的制作网站上用纯文本打印了十几次

我在该网站的本地版本发布之前对其进行了测试,在那里运行良好。我很快恢复了更改,并在开发网站上进行了测试。当存储在PHP代码中时,它在开发服务器上运行良好。我还在开发服务器的phpMyAdmin界面上测试了它,在那里它工作得很好。我登录到生产网站的phpMyAdmin界面,并在那里运行查询,结果失败,出现了相同的错误。我分别对每个表运行查询,它们顺利通过,没有出现错误

什么给了我


制作网站已经很过时了。它运行的是FreeBSD 6.4是的,EOL是2010年11月30日。。。MySQL 5.1是的,EOL是2013年12月31日。。。。我正在将其从共享主机移动,以便更新它。开发服务器是当前的Bitnami LAMP stack虚拟机,运行Ubuntu 14.04和MySQL 5.5。到目前为止,我还没有遇到兼容性问题。据我所知,查询没有使用两个版本之间的任何不同语法或特殊功能。

我作为管理用户登录到数据库,它返回错误:

1146-表“company.pimage”不存在

这很快就解决了原来的问题:pimage和pimage之间的一个愚蠢的案例错误

区分大小写 之前没有检测到此错误,因为Bitnami设备的默认值已更改,使其表名不区分大小写,并且MySQL中针对非管理员用户的错误消息没有泄漏信息

MySQL文档,请阅读:

默认情况下,Unix上的表别名区分大小写

但这可以通过系统变量进行更改

如果设置为0,则按指定存储表名,并且比较区分大小写。如果设置为1,则表名以小写形式存储在磁盘上,并且比较不区分大小写。如果设置为2,则表名按给定值存储,但以小写形式进行比较。。。 在Unix上,小写字母表名称的默认值为0。在Windows上,默认值为1。在OSX上,默认值为2

在我的开发服务器上,SHOW VARIABLES表明Bitnami设备将此值设置为1。mysqld-verbose-help建议编译后的默认值设置为零,但/opt/bitnami/mysql/scripts/ctl.sh sets-lower-case table names=1

隐秘的错误消息 非管理员用户的错误消息很神秘:

1142-SELECT命令拒绝给用户的user@localhost'对于表'mispelled_table'

但是管理员用户的错误消息:

1146-表“company.mispelled_Table”不存在

很容易理解。管理员用户具有当前用户权限的显示授权:

GRANT USAGE ON *.* TO 'admin_user'@'%' IDENTIFIED BY PASSWORD [redacted]
GRANT ALL PRIVILEGES ON `company`.* TO 'admin_user'@'%' WITH GRANT OPTION
但普通用户具有以下权限:

GRANT USAGE ON *.* TO 'user'@'localhost' IDENTIFIED BY PASSWORD [redacted]
GRANT SELECT ON `schap`.`pImage` TO 'user'@'localhost'
GRANT SELECT, SELECT (view_count), UPDATE (view_count) ON `company`.`products` TO 'user'@'localhost'
...etc.
最后一点只是猜测,因为我没有更改和测试它所需的权限,但我认为会给用户提供良好的错误消息。避免列出所有数据库名称可能是一个不错的策略,因为它可以防止黑客很容易地确定哪些表存在,但它肯定会造成很多混乱