lukasandClaude Opus 4.8
4e077f1a37
Backend foundation for the plugin platform (SPEC §11), Phases 1-3.
Phase 1 — SDK + loader:
- app/plugins/types.py: frozen Plugin/UiManifest/Slot/Page/JobSpec contract.
- app/plugins/sdk.py: sdk(name) facade — the only app.* import allowed for plugins
(scoped session, plugin.{name}.* publish, blob, outbox, settings, SSRF http_get, KV, enqueue).
- app/plugins/loader.py: entry-point discovery (webmail.plugins), hook forwarding
(API + worker), router mounting at /api/plugins/{name}, ui-manifest aggregation.
- plugin_kv core table (migration 0013) + GET /api/plugins/ui-manifest.
Phase 2 — non-removable core plugins + DB-enforced privacy:
- builtin flag (calendar/contacts will be builtin=True; uninstall refuses them).
- RLS per-user isolation on plg_* tables: least-privilege webmail_plugin role
(migration 0014), plugin_session(user_id) sets LOCAL ROLE + app.current_user_id,
rls.enable_rls() (ENABLE+FORCE RLS + USING/WITH CHECK policy). Mail untouched.
- Per-plugin Alembic runner (shared env, dedicated version table) + install/uninstall
--drop-data CLI; skeleton fixture proves install -> run -> uninstall --drop-data
leaves zero residue (§12 M3 acceptance).
Phase 3 — plugin jobs (§11.2):
- JobSpec registered as arq function plg.{plugin}.{func} + cron (5-field parser);
singleton=True guarded by a per-(plugin,user) Redis lock; wired onto the shared
interactive worker.
Gates: ruff, mypy --strict (94 files + tests), full suite 326 passed. RLS isolation,
migration round-trip, and singleton lock covered by tests.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rcj3TpydMTzTSmU7kunzf8
47 lines
2.0 KiB
Python
47 lines
2.0 KiB
Python
"""Row-Level Security for plugin-owned tables (SPEC §11.1 + privacy hardening).
|
|
|
|
Per-user isolation for ``plg_*`` tables is enforced by Postgres, not by remembering
|
|
a ``WHERE user_id = ?`` in every query. Each user-data table gets RLS enabled +
|
|
forced, with a policy comparing ``user_id`` to the transaction-local GUC
|
|
``app.current_user_id``. Plugin code reaches these tables only through
|
|
``sdk.session(user_id)`` (see :mod:`app.plugins.db`), which drops to the
|
|
least-privilege :data:`PLUGIN_ROLE` and binds that GUC — so even a query that
|
|
forgets to filter cannot see or write another user's rows.
|
|
|
|
Plugin migrations call :func:`enable_rls` right after creating a user-data table.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
# NOLOGIN, non-superuser, NOBYPASSRLS role plugin sessions SET LOCAL ROLE into
|
|
# (created by core migration 0014). RLS is skipped for superusers / table owners /
|
|
# BYPASSRLS roles, so plugin access must run as this restricted role to be enforced.
|
|
PLUGIN_ROLE = "webmail_plugin"
|
|
|
|
_USER_CTX = "current_setting('app.current_user_id', true)::uuid"
|
|
|
|
|
|
def rls_ddl(table: str, *, user_column: str = "user_id") -> list[str]:
|
|
"""SQL statements that lock ``table`` to the current user (SPEC §11.1).
|
|
|
|
Pure/testable: returns the DDL rather than executing it. ``FORCE`` makes even
|
|
the table owner subject to the policy; ``WITH CHECK`` blocks inserting/updating
|
|
rows for a different user."""
|
|
policy = f"{table}_user_isolation"
|
|
return [
|
|
f"ALTER TABLE {table} ENABLE ROW LEVEL SECURITY",
|
|
f"ALTER TABLE {table} FORCE ROW LEVEL SECURITY",
|
|
f"CREATE POLICY {policy} ON {table} "
|
|
f"USING ({user_column} = {_USER_CTX}) "
|
|
f"WITH CHECK ({user_column} = {_USER_CTX})",
|
|
f"GRANT SELECT, INSERT, UPDATE, DELETE ON {table} TO {PLUGIN_ROLE}",
|
|
]
|
|
|
|
|
|
def enable_rls(table: str, *, user_column: str = "user_id") -> None:
|
|
"""Apply :func:`rls_ddl` via Alembic ``op`` — call from a plugin migration."""
|
|
from alembic import op
|
|
|
|
for statement in rls_ddl(table, user_column=user_column):
|
|
op.execute(statement)
|