124 lines
4.9 KiB
Markdown
124 lines
4.9 KiB
Markdown
# 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 PostgreSQL[^1] 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](https://www.postgresql.org/docs/current/sql-set-role.html).
|
|
`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. `phono_{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.
|
|
|
|
## Footnotes
|
|
|
|
[^1]:
|
|
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.
|