1. 为何数据库级ALL PRIVILEGES权限不足？ #

PostgreSQL的权限是分层独立的：数据库级权限（如CONNECT、CREATE DATABASE等）和Schema级、对象级权限互不包含。给用户授予数据库的ALL PRIVILEGES，仅覆盖数据库层面的权限，不会自动获得该数据库下Schema的操作权限。

默认状态下，public Schema的权限仅对超级用户和Schema所有者开放。普通用户即便拥有数据库访问权限，若没有public Schema的USAGE（访问Schema内对象）和CREATE（在Schema内创建对象）权限，就会触发建表时的权限拒绝错误。

你提到授予Schema权限无效，大概率是执行环节的问题：

• 必须先连接到test_db数据库再执行授权命令，否则权限会被授予当前连接的其他数据库（比如默认的postgres库）
• 正确的授权命令示例：

  -- 切换到test_db数据库
  \c test_db
  -- 授予public Schema的核心权限
  GRANT USAGE, CREATE ON SCHEMA public TO testuser;
  

2. 授予public schema权限是否会影响其他数据库？ #

不会。每个PostgreSQL数据库的public Schema是独立存在的，权限配置仅作用于当前数据库的public Schema。在test_db中给testuser授予public Schema权限，完全不会影响其他数据库的public Schema或权限设置。

3. 角色权限管理最佳实践 #

• 最小权限原则：仅授予用户完成工作所需的最小权限，避免直接赋予数据库所有权或超级用户权限
• 分层授权：明确区分数据库级（CONNECT）、Schema级（USAGE、CREATE）、对象级（表的SELECT/INSERT等）权限，按需逐层授予
• 使用角色组管理：创建权限角色（如test_db_editor），将所需权限集中授予角色组，再把用户加入对应角色组，便于批量管理和权限变更
• 合理配置默认权限：若需要让用户访问后续创建的对象，可设置默认权限（仅对设置后创建的对象生效）：

  ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT USAGE, SELECT ON SEQUENCES TO testuser;
  ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO testuser;
  

• 避免过度依赖public Schema：建议创建自定义Schema管理业务对象，减少对默认public Schema的权限修改，降低权限泄露风险
• 定期审计权限：使用\dp（查看对象权限）、\l+（查看数据库权限）、\du（查看角色权限）等命令定期检查权限配置，清理冗余权限

内容的提问来源于stack exchange，提问作者tallow_amnesty