我帮你拆解下这个问题——你遇到的是Presto启用sql-standard安全模式后，和Hive metastore权限交互的典型故障：Beeline能正常执行是因为它直接对接Hive原生的权限逻辑，而Presto这边因为身份传递或配置的疏漏，没正确识别执行查询的用户身份，导致不管是谁查什么表都触发权限拒绝。结合你无Kerberos、hive.metastore.authentication.type=NONE的配置，按下面的步骤排查解决：

1. 确认Presto Hive连接器的身份传递配置 #

当hive.security=sql-standard时，Presto会依赖客户端传递的用户身份去Hive metastore校验权限。如果Presto没拿到正确的用户，会默认用Presto服务进程的系统用户（比如presto）去做校验，这个用户大概率没有目标表的权限。

打开你的Presto Hive连接器配置文件（通常是etc/catalog/hive.properties），确保以下配置正确：

• 添加hive.metastore.client.authentication.type=NONE，和你的Hive metastore配置保持一致，让Presto能无认证访问metastore
• 检查http-server.properties里的http.authentication.type：如果设为NONE，Presto会信任客户端传来的X-Presto-User头；如果是其他认证方式（比如PASSWORD），要确保认证后的用户能正确传递到Hive连接器。

2. 验证客户端传递的用户身份是否正确 #

用Presto CLI执行查询时，默认会用当前操作系统用户作为查询用户。你可以先验证下：

• 在CLI里执行SELECT current_user();，看看返回的是不是你预期的、在Hive里有对应表权限的用户
• 如果需要指定用户查询，启动CLI时加--user参数：

  presto --user 你的Hive用户名 --catalog hive --schema 你的库名
  

  再试一次查询，看是否还报错。

3. 刷新Presto的权限缓存 #

有时候Presto的权限缓存会和Hive metastore里的实际权限不一致，导致误判。你可以：

• 在Presto CLI里执行SYSTEM FLUSH PRIVILEGES;，强制Presto重新从Hive metastore拉取最新的权限数据
• 如果还是不行，重启下Presto集群，让所有节点加载最新的配置和权限信息

4. 检查sql-standard模式的权限逻辑差异 #

hive.security=sql-standard是严格遵循SQL标准的权限模型，和Hive默认的权限模型有区别：

• 确保目标表的SELECT权限是明确授予给查询用户的，比如执行过GRANT SELECT ON TABLE 你的表名 TO USER 你的Hive用户名;，而不是只依赖表所有者的权限
• 别忘了检查数据库级别的权限，sql-standard模式下，用户得先有访问对应数据库的权限，才能访问库里的表

5. 排查Presto服务进程的系统权限 #

最后，检查运行Presto的系统用户（比如presto）是否能正常访问Hive相关资源：

• 确保这个用户能连接Hive metastore（虽然你设了authentication.type=NONE，但网络、防火墙层面别限制了）
• 检查HDFS上的表数据路径、Hive metastore的存储路径，这个系统用户得有读权限

内容的提问来源于stack exchange，提问作者Andrea T. Bonanno