PostgreSQL中USAGE与SELECT权限的关系及授权顺序分析

核心权限概念

在PostgreSQL项目中（例如构建PostgREST服务），通常需要创建专用角色以最小化权限风险。最基础的操作包含创建非登录角色，并为其分配特定权限：

CREATE ROLE web_anon NOLOGIN;
GRANT USAGE ON SCHEMA api TO web_anon;
GRANT SELECT ON api.todos TO web_anon;

CREATE ROLE web_anon NOLOGIN：创建一个名为 web_anon 的新角色。关键字 NOLOGIN 确保该角色无法直接连接数据库，通常作为应用后台角色的“容器”或供其他用户继承使用。

后两条命令是权限控制的核心：GRANT USAGE 针对模式（Schema），GRANT SELECT 针对具体的表。

仅有SELECT权限会发生什么？

如果跳过 USAGE 权限，仅授予角色对表的 SELECT 权限，情况会较为特殊但往往不符合预期：

• 基础查询可能受限：虽然某些简单场景下能查到表数据，但如果查询涉及到该 Schema 中的自定义类型、操作符或函数，会因为缺少 USAGE 权限而报错。
• 对象隔离：USAGE 权限决定了角色能否看到并使用 Schema 下的其他“工具”（如自定义函数）。没有它，角色会被限制在纯粹的表数据访问上，且容易在处理复杂查询时受阻。

仅有USAGE权限会发生什么？

许多开发者误以为有了 USAGE 就能查表，这是不正确的。USAGE 权限并不包含对表数据的读取权。

让我们通过一个包含自定义数据类型和函数的完整案例来演示。

第一步：准备测试环境

首先，在 api Schema 中创建自定义枚举类型、使用该类型的表以及一个辅助函数：

-- 1. 创建自定义枚举类型
create type api.priority_level as enum('Low', 'Medium', 'High');

-- 2. 创建包含该类型的表
create table api.todos_with_priority (
    id serial primary key,
    task varchar(255) not null,
    priority api.priority_level not null
);

-- 3. 创建使用该类型的函数
create function api.get_priority_as_text(p api.priority_level) returns text
    language sql as $$ 
        select 'Priority: ' || p::text; 
    $$;

第二步：仅授予USAGE权限

创建角色并仅赋予 Schema 使用权：

create role web_anon nologin;
grant usage on schema api to web_anon;

此时尝试查询：

select id, task, api.get_priority_as_text(priority)
from api.todos_with_priority;

结果：查询失败。 尽管角色可以使用函数 api.get_priority_as_text，但因为缺乏表 api.todos_with_priority 的 SELECT 权限，数据库拒绝返回数据。

第三步：补全权限

为了使 web_anon 能够正常查询，必须显式授予表的 SELECT 权限：

grant select on api.todos_with_priority to web_anon;

现在角色既能处理基于自定义类型的逻辑（得益于USAGE），又能读取表内容（得益于SELECT）。

总结

在PostgreSQL的权限体系中，USAGE 和 SELECT 各司其职：

1. SCHEMA USAGE：决定能否使用架构内的非表对象（如类型、函数、序列等）。
2. TABLE SELECT：决定能否读取指定表的数据行。

要实现标准的只读数据访问，必须同时授予这两个权限。忽略其中任何一个都可能导致功能缺失或安全漏洞。以上就是PostgreSQL中USAGE与SELECT权限关系及操作方案的详细内容，更多关于PostgreSQL权限管理的资料请关注本站其它相关文章！