listmonk 给 subscribers:sql_query 权限前如何创建受限的 Postgres 角色【免费下载链接】listmonkHigh performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.项目地址: https://gitcode.com/GitHub_Trending/li/listmonklistmonk 的 subscribers 界面和 API 支持通过query参数执行任意 SQL 表达式该能力被放在subscribers:sql_query这个权限后面用户角色体系从 listmonk v4.0.0 起可用。官方文档在 roles-and-permissions.md 中明确警告这个权限虽然对表数据是只读的但允许绕过逐列表、逐订阅者的权限直接从数据库查询所有列表和订阅者并且可以通过原始 SQL 读取 Postgres 数据库配置、与其他 Postgres 系统功能交互。因此文档建议如果要把这个权限分配给多个用户先创建一个禁止任何特权操作的自定义 Postgres 角色让 listmonk 用这个角色连接数据库然后再在管理界面分配权限。本文的操作路径是理解风险 → 创建受限角色 → 把 listmonk 的数据库连接指向该角色 → 在用户角色中分配subscribers:sql_query→ 对照文档确认边界。为什么需要先建受限角色按 roles-and-permissions.md 的说明subscribers:sql_query允许用户编写并执行任意 SQL 查询查询以只读事务执行不能修改数据库表中的数据但它可以直接查询所有列表、订阅者和其他数据绕过单独的列表和订阅者权限原始 SQL 表达式还可以获取 Postgres 数据库配置并可能与其他 Postgres 系统功能交互。security-reports.md 进一步解释了为什么 listmonk 自身无法堵住这一点Postgres 本身没有提供允许/禁止特定函数的简单方式listmonk 只能保证查询以只读方式执行并对目标表做基本检查以防意外的副作用。所以风险控制的另一层要放在数据库账号上文档给出的建议是“创建一个禁止任何特权操作的自定义 Postgres 角色”。创建受限的 Postgres 角色在 listmonk 使用的那个 Postgres 实例上连接信息即 [db] 配置见 config.toml.sample执行文档给出的示例语句CREATE ROLE listmonk_app WITH LOGIN PASSWORD ... NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;说明PASSWORD ...中的...是文档留下的占位符替换为你自己设定的密码。这个密码后面要与 listmonk 配置里的 [db]password一致。listmonk_app是文档示例中的角色名需要与 listmonk [db] 配置中的user保持一致listmonk 会用它登录数据库。NOSUPERUSER、NOCREATEDB、NOCREATEROLE、NOREPLICATION对应文档所说的“disallowing any privileged operations”即禁止该角色的特权操作LOGIN使该角色可以登录。文档没有逐项解释这些标志的默认行为以 Postgres 官方文档为准。角色创建成功后该角色具备登录能力但不具备超级用户、创建数据库、创建角色、复制这些特权能力。让 listmonk 用该角色连接数据库listmonk 的数据库连接配置在 TOML 配置文件的 [db] 段也可用LISTMONK_前缀的环境变量提供见 configuration.md。按 config.toml.sample 的 [db] 段结构把user和password改为刚创建的角色[db] host localhost port 5432 user listmonk_app password ... database listmonk ssl_mode disable其中password填你在CREATE ROLE中设置的密码host、port、database按你现有的 Postgres 实例填写示例值来自 config.toml.sample。如果使用 Docker Compose 等以环境变量方式配置对应变量为LISTMONK_db__user、LISTMONK_db__password等格式见 configuration.md 的 Supported variables 表。注意切换连接角色前请确认该角色对 listmonk 的数据库有正常使用权限。文档只给出了受限角色的创建示例没有列出该角色需要的表级授权清单这部分需要按你数据库的授权现状处理本文不代替你判断。分配 subscribers:sql_query 权限数据库侧就绪后再在 listmonk 管理界面分配权限进入Admin - Users - User roles。用户角色是一组用户相关权限的集合角色绑定到用户账号上见 roles-and-permissions.md 的 User roles 一节。在目标用户角色中加入subscribers:sql_query并把该角色分给需要执行原始 SQL 查询的用户。权限表对这条权限的原文警告是“Give this permission ONLY to trusted users”只交给可信用户。数据库角色去掉特权操作后只能降低误操作和越权的风险面不能阻止用户读取 Postgres 配置或调用其他系统功能所以“可信用户”这个前提仍然成立。验证与边界完成上述步骤后按文档描述核对以下几点拥有该权限的用户执行查询时查询以只读事务运行无法修改数据库表数据listmonk 同时会对目标表做基本检查以防意外副作用security-reports.md。该权限会绕过单独的列表和订阅者权限被授权用户能直接查询所有列表和订阅者的数据即使他没有对应的列表角色或subscribers:get_all。分配前需要意识到这一点。该角色没有SUPERUSER、CREATEDB、CREATEROLE、REPLICATION能力特权操作在数据库层被拒绝但 Postgres 没有提供允许/禁止特定 SQL 函数的简单方式任意 SQL 表达式仍可读取数据库配置并交互其他系统功能。这是文档明确给出的残留风险不是本次配置能消除的。至此受限 Postgres 角色已就位subscribers:sql_query只发放给可信用户数据库账号本身也不再持有特权操作能力。若后续新增需要该权限的用户直接在已有用户角色上分配即可无需再改动 Postgres 侧配置。【免费下载链接】listmonkHigh performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.项目地址: https://gitcode.com/GitHub_Trending/li/listmonk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
