# 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 cluster 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. The user's actual ability to connect to the database should
always be confirmed before actually fetching data or metadata from a backing
database.

**Caution!** The Postgres database `CONNECT` privilege has no effect after a
connection has been established, and _it is not re-checked by Postgres when
running the `SET USER` command_. **The Phonograph server is solely responsible
for managing top-level workspace permissions when accessing data via
established, pooled connections.**

### 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.

Note that granting insert or update privileges on specific columns will be
reflected in relation ACLs (that is, in the `pg_class` table) as the
corresponding privilege on the relation overall. In other words, a role listed
as having insert and/or update permissions in a relation's ACL items might not
have insert and/or update permissions to all columns.

### 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.

Note that granting insert or update privileges on specific columns will be
reflected in relation ACLs (that is, in the `pg_class` table) as the
corresponding privilege on the relation overall. In other words, a role listed
as having insert and/or update permissions in a relation's ACL items might not
have insert and/or update permissions to all columns.

## 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.
