Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

docs(breg): state that the migration role must not hold CREATE on the database in Provision PostgreSQL

未关闭 适合新手
  • 哪里不对？
#2,302 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@jeremi 已经在做这个了。

开始于 2026年10月22日。

  • #2305 来自 @jeremi —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
82/100
Issue 类型
文档
描述清晰度
描述清楚
活跃度
活跃
技术栈
postgresql
领域
databases, documentation

调研方向

阅读 docs/site/src/content/docs/operate/breg.mdx 中的 “Provision PostgreSQL” 部分，并将其中关于角色的说明与 crates/registry-breg/src/postgres/roles.rs 中的 verify_migration_role 进行对照。更新主章节，说明迁移角色不得拥有该数据库，也不得在其中持有 CREATE 权限，并添加相关的证据注释。完成标准：非空间功能设置的读者能够看到此要求，且文档记载的角色权限与强制执行的规则一致。

由索引模型根据 Issue 内容生成。

描述

area:breg area:docs documentation

Problem

docs/site/src/content/docs/operate/breg.mdx, section "Provision PostgreSQL", never says that the migration role must not hold CREATE on the database, and must not own the database (an owner holds CREATE implicitly). The main block revokes database privileges from PUBLIC only (REVOKE ALL ON DATABASE registry FROM PUBLIC;); the only revoke that names the registry roles is REVOKE CREATE ON DATABASE registry FROM PUBLIC, registry_migration, registry_runtime; inside the spatial subsection, so a reader of a non-spatial project has no reason to check it. PostgreSQL does not grant database CREATE to PUBLIC by default, so the risk is an explicit grant or ownership the administrator's own tooling adds (for example CREATE DATABASE registry OWNER registry_migration, or a hosted provider's setup script).

Where

  • Docs: docs/site/src/content/docs/operate/breg.mdx, "Provision PostgreSQL" (lines 140 to 201 on origin/main; identical on jeremi/documents).
  • Enforcement: crates/registry-breg/src/postgres/roles.rs, verify_migration_role (lines 401 to 431 on origin/main). It refuses when has_database_privilege(current_user, current_database(), 'CREATE') is true, as it does for SUPERUSER, BYPASSRLS, CREATEDB and CREATEROLE, with RoleInvariant("migration role has database-level administrative authority"). The same function then requires the migration role to own all five managed schemas (verify_schema_owner).
  • It runs on every apply connection (interlock.rs, acquire_inner, line 286), in schema preparation for bregctl test (schema.rs), and in the maintenance commands.

What goes wrong

The refusal is correct and happens before maintenance, so nothing is written. But the operator is not told why:

  • bregctl apply and bregctl plan report apply.migration.failed with "requires exact-target reconciliation" and suggested action reconcile-failed-migration (see #1381), which sends them to migration reconcile for a database that was never touched.
  • bregctl test most likely reports test.database.unavailable ("recreate the disposable database"), because schema_preparation_error in crates/registry-bregctl/src/test_lifecycle.rs collapses every other StartupError to TestLifecycleError::Database. I did not trace the RoleInvariant to StartupError mapping for this exact case.

During the 2026-10-22 root-cause investigation, the repro databases gave the migration role CREATE on the database and lacked the five managed schemas; the documented setup passed with v0.43.0.

Proposed direction

In the main "Provision PostgreSQL" text (not only the spatial block):

  1. One sentence: the migration role must not own the database or hold CREATE on it; it owns only the five schemas, and test and apply refuse a role with database-level authority.
  2. Optionally add REVOKE CREATE ON DATABASE registry FROM registry_migration, registry_runtime; to the main block, so the spatial block's revoke is not the only one.
  3. Add crates/registry-breg/src/postgres/roles.rs, verify_migration_role to the Evidence comment.

Notes

  • Confirmed in code: the CREATE refusal, its message, where it runs, and the docs text on origin/main.
  • From the triage notes, not reproduced by me: the repro databases' exact grants.
  • Inferred: the bregctl test code for this case.
  • The misleading apply code is #1381; this issue is docs only.
主要语言
Rust
星标
2
派生
0
平均合并
9 小时 43 分钟
30 天内合并 PR
268

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

registrystack/registry-stack 的其他 Issue

查看 registrystack/registry-stack 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。