ConusAI vendor v0.1.0-beta.114

dev/postgres-entrypoint.sh

@@ -0,0 +1,11 @@
+#!/bin/sh
+# SPDX-License-Identifier: LicenseRef-ConusAI-Template-1.0
+# The local Postgres's entrypoint (compose.dev.yaml, the e2e stacks, test/relay-scope.test.ts): installs
+# `postgres-roles.sql` for the image's first start with a mode the server can read, then runs the image's own
+# entrypoint. The checkout's file mode depends on the host (a clone under `umask 077` writes it 0600, and
+# under rootless Docker the server's user cannot read that), so the script is not mounted where the server
+# reads it: the container's root, which can, copies it there. It runs as `sh <file>`, so it needs no mode of
+# its own either.
+set -eu
+install -m 0644 /conusai-dev/postgres-roles.sql /docker-entrypoint-initdb.d/10-roles.sql
+exec docker-entrypoint.sh "$@"

dev/postgres-roles.sql

@@ -0,0 +1,37 @@
+-- SPDX-License-Identifier: LicenseRef-ConusAI-Template-1.0
+-- The three roles a linked managed Postgres exposes, created the way the platform creates them
+-- (docs/architecture/managed-postgres-roles.md, data-services DS21). Development only: on the
+-- platform these statements are the provider's, and the passwords are derived, not written down.
+--
+-- Owner    appdev_owner   owns the database and schema public; the migrate job's role
+-- Runtime  appdev_app     owns nothing, so row-level security binds it; web and worker
+-- Reader   appdev_reader  holds no table privilege until this app's own migrations grant one
+
+CREATE ROLE appdev_owner  LOGIN PASSWORD 'appdev_owner'  NOSUPERUSER NOCREATEDB NOCREATEROLE NOBYPASSRLS NOINHERIT NOREPLICATION;
+CREATE ROLE appdev_app    LOGIN PASSWORD 'appdev_app'    NOSUPERUSER NOCREATEDB NOCREATEROLE NOBYPASSRLS NOINHERIT NOREPLICATION;
+CREATE ROLE appdev_reader LOGIN PASSWORD 'appdev_reader' NOSUPERUSER NOCREATEDB NOCREATEROLE NOBYPASSRLS NOINHERIT NOREPLICATION;
+
+ALTER DATABASE "appdev" OWNER TO "appdev_owner";
+REVOKE ALL ON DATABASE "appdev" FROM PUBLIC;
+GRANT CONNECT, TEMPORARY ON DATABASE "appdev" TO "appdev_owner";
+GRANT CONNECT ON DATABASE "appdev" TO "appdev_app";
+GRANT CONNECT ON DATABASE "appdev" TO "appdev_reader";
+
+\connect appdev
+
+ALTER SCHEMA public OWNER TO "appdev_owner";
+REVOKE ALL ON SCHEMA public FROM PUBLIC;
+GRANT ALL ON SCHEMA public TO "appdev_owner";
+GRANT USAGE ON SCHEMA public TO "appdev_app";
+GRANT USAGE ON SCHEMA public TO "appdev_reader";
+
+-- No IN SCHEMA clause: every table the owner creates, in any schema a migration adds, is granted
+-- to the runtime role as it is created. There is no grant pass left to run after a migration.
+ALTER DEFAULT PRIVILEGES FOR ROLE "appdev_owner" GRANT USAGE ON SCHEMAS TO "appdev_app";
+ALTER DEFAULT PRIVILEGES FOR ROLE "appdev_owner" GRANT USAGE ON SCHEMAS TO "appdev_reader";
+ALTER DEFAULT PRIVILEGES FOR ROLE "appdev_owner" GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "appdev_app";
+ALTER DEFAULT PRIVILEGES FOR ROLE "appdev_owner" GRANT USAGE, SELECT ON SEQUENCES TO "appdev_app";
+ALTER DEFAULT PRIVILEGES FOR ROLE "appdev_owner" GRANT EXECUTE ON FUNCTIONS TO "appdev_app";
+
+-- The reader gets nothing here. What it may read is this app's decision, and it is a GRANT in
+-- migrations/postgres/0002_reader_grants (apps/worker/src/migrations.ts).