Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
#2,302 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
82/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
postgresql

Línea de trabajo

Lee la sección “Provision PostgreSQL” en docs/site/src/content/docs/operate/breg.mdx y compara sus indicaciones sobre el rol con verify_migration_role en crates/registry-breg/src/postgres/roles.rs. Actualiza la sección principal para indicar que el rol de migración no debe ser propietario de la base de datos ni tener CREATE en ella, y añade el comentario de evidencia pertinente. Se considera terminado cuando los lectores de la configuración no espacial puedan ver este requisito y los permisos del rol documentados coincidan con la aplicación de la regla.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
2
Forks
0
Merge medio
9 h 19 min
PR fusionados (30 d)
275

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de registrystack/registry-stack

Todos los issues de registrystack/registry-stack

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.