5.1 KiB
Phonograph (FKA Interim)
A friendly, collaborative PostgreSQL derivative for nerds of all stripes.
The Phonograph Authorization Model
Postgres provides a sophisticated role based access control (RBAC) system, which Phonograph leverages to apply permissions consistently across the web UI and inbound PostgreSQL1 connections.
In order to efficiently pool database connections from the application server,
most actions initiated via the web UI are run as the corresponding database user
role using the
SET ROLE command.
SET ROLE does not provide great insulation against privilege escalation.
Queries which are not thoroughly validated and escaped must only be run via a
dedicated connection initiated with the user-level role's credentials.
Given complete freedom it is possible, in fact easy, to configure a Postgres table into what would be considered an "invalid" state by Phonograph, so table creation and ownership is restricted to the "root" Phonograph role, which acts on the behalf of the user in order to facilitate schema updates via the web interface.
Permissions Granted via User Roles
Accessing workspace databases
GRANT CONNECT ON <database> TO <role>;
This permission is granted when initially creating the workspace, as well as when accepting an invitation to a table.
Access to workspaces is controlled via the CONNECT ON DATABASE permission.
However, it is unreasonable to query every backing database to compute the set
of workspaces to which a user has access, so Phonograph caches workspace-level
"connect" permissions in its own centralized table (workspace_memberships).
workspace_memberships rows are added whenever the GRANT CONNECT command is
run, and are deleted after a REVOKE CONNECT command is run.
It is possible that an error occurs after REVOKE CONNECT but before the
membership record is deleted. Therefore for authorization purposes, membership
of a workspace is not a guarantee that the user has CONNECT privileges, just
that they might. In cases where the root Postgres user is fetching potentially
sensitive data on behalf of a user, the user's actual ability to connect to the
database should always be confirmed.
Accessing the phono schema
GRANT USAGE ON <schema> TO <role>;
This permission is granted when initially creating the workspace, as well as when accepting an invitation to a table.
Creating, updating, and deleting columns
GRANT <table owner role> TO <role>;
This permission is granted when initially creating the table, as well as when accepting an invitation to a table, if the invitation includes "owner" permissions.
This permission is only used via the web UI and must not be granted to service credentials, lest users alter table structure in unsupported ways.
Reading table data
GRANT SELECT ON <table> TO <role>;
This permission is granted when initially creating the table, as well as when accepting an invitation to the table.
Phonograph uses SELECT permissions to infer whether a table should be
accessible to a user via the web UI.
Inserting rows
GRANT INSERT (<columns>) ON <table> TO <role>;
Write-protected columns (_id, etc.) are excluded.
This permission is granted when initially creating the table, as well as when accepting an invitation to the table, if the invitation includes "edit" permissions.
These permissions must be updated for each relevant user role whenever a column is added; this is simplified by maintaining a single "writer" role per table.
Updating rows
GRANT UPDATE (<columns>) ON <table> TO <role>;
Write-protected columns (_id, etc.) are excluded.
This permission is granted when initially creating the table, as well as when accepting an invitation to the table, if the invitation includes "edit" permissions.
These permissions must be updated for each relevant user role whenever a column is added; this is simplified by maintaining a single "writer" role per table.
Actions Facilitated by Root
- Creating tables
Service Credentials
Direct user PostgreSQL connections are performed using secondary LOGIN roles
created by the user's primary workspace role (where the primary workspace role
is e.g. usr_{user_id}). The credentials for these secondary roles are referred
to as "service credentials" or "PostgreSQL credentials". Service credentials are
created and assigned permissions by users in the web UI, and their permissions
are revoked manually in the web UI and/or by cascading REVOKE commands
targeting the primary workspace role.
Service credential role names have the format
svc_{user_id}_{8 chars (4 bytes) of random hex}. With the user ID consuming 32
characters, this balances name length with an ample space for possible names.
Footnotes
-
Barring historical pedantry, "Postgres" and "PostgreSQL" are essentially synonymous and are often used interchangeably. As a matter of convention throughout Phonograph docs, "Postgres" is largely used to refer to the database software, while "PostgreSQL" is typically used to refer to the query language and/or wire protocol. ↩︎