The console connects to its database as a superuser, so the privilege revokes bind nothing #23

New Issue

2026-09-21T07:18:08Z

cgalo5758 commented

2026-09-21 07:18:08 +00:00

What happens

The migrations that enclose the entitlement ledger revoke direct writes on those tables from the writer role, so that only the enclosed functions can change them, and the console's login is granted that role. The login the console actually connects with is the database container's bootstrap user, which the database creates as a superuser, and a superuser bypasses every privilege check. The revokes are therefore inert wherever the console runs, in the test stack and in a deployment created the same way.

What should happen

The console connects as an ordinary role, so a stray write to an enclosed table is refused by the database rather than by convention, and the enclosure means what the schema says it means.

Where

The migration that creates the roles and the console's login; the test stack's compose file, where the login is the bootstrap user; the deployment documentation.

Steps

Connect as the console's configured login and write a row directly into one of the enclosed tables. The write succeeds. Set the role to the writer role first and the same write is refused, which is what the existing test does.

Why it matters

The enclosure is the last defence under the ledger and the reason the enclosed functions are the only documented way in. Today it holds only inside a test that sets the role by hand. The fix is a non-superuser login for the console in both stacks, the bootstrap superuser kept for migrations and operations, and a boot-time refusal to start as a superuser outside development mode.

Migrated from status/issues.md at b7a0e15

## What happens The migrations that enclose the entitlement ledger revoke direct writes on those tables from the writer role, so that only the enclosed functions can change them, and the console's login is granted that role. The login the console actually connects with is the database container's bootstrap user, which the database creates as a superuser, and a superuser bypasses every privilege check. The revokes are therefore inert wherever the console runs, in the test stack and in a deployment created the same way. ## What should happen The console connects as an ordinary role, so a stray write to an enclosed table is refused by the database rather than by convention, and the enclosure means what the schema says it means. ## Where The migration that creates the roles and the console's login; the test stack's compose file, where the login is the bootstrap user; the deployment documentation. ## Steps Connect as the console's configured login and write a row directly into one of the enclosed tables. The write succeeds. Set the role to the writer role first and the same write is refused, which is what the existing test does. ## Why it matters The enclosure is the last defence under the ledger and the reason the enclosed functions are the only documented way in. Today it holds only inside a test that sets the role by hand. The fix is a non-superuser login for the console in both stacks, the bootstrap superuser kept for migrations and operations, and a boot-time refusal to start as a superuser outside development mode. Migrated from status/issues.md at b7a0e15

cgalo5758 added this to the Public launch milestone 2026-09-21 07:18:08 +00:00

cgalo5758 added the

kind

bug

area/ops security labels 2026-09-21 07:18:08 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#23