Least-privilege role model + SECURITY DEFINER audit (1.1.0 scope) #5

Summary

Add a least-privilege role model so consumers can connect with a restricted database role instead of the schema owner. The MSSQL provider ships permissions.sql creating a dt_runtime role and GRANTing EXECUTE on every object; PostgreSQL has no equivalent.

Scope (1.1.0)

1. Add a permissions.postgresql.sql script: CREATE ROLE dt_runtime + GRANT USAGE ON SCHEMA dt + GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA dt TO dt_runtime + GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA dt TO dt_runtime. (One GRANT ... ALL FUNCTIONS replaces MSSQL's ~20 individual GRANTs.)
2. Embed and optionally auto-run it after logic.sql in DeploySchemaScriptsAsync (mirrors MSSQL SqlDbManager).
3. Design wrinkle to resolve: current_task_hub() is declared SECURITY DEFINER (schema.postgresql.sql), so every function that calls it (all of them) executes as the schema owner. A least-privilege dt_runtime role is therefore decorative until this is addressed. Options: (a) change current_task_hub() to SECURITY INVOKER and grant the role SELECT on dt.global_settings; or (b) make all data functions SECURITY DEFINER and hide tables from the runtime role. Option (a) is simpler and more honest.

Reference

• MSSQL: src/DurableTask.SqlServer/Scripts/permissions.sql (51 LOC, 20 GRANTs).
• Local upstream sources documented in AGENTS.md.
• Estimated effort: 0.5-1 day for the GRANT script + 0.5 day for the SECURITY DEFINER audit/decision.

Why 1.1.0

Most users run with a single privileged role; least-privilege is an operational hardening concern, not a correctness blocker. Document the GRANT pattern in the README for 1.0.0; ship the full auto-deploy in 1.1.0.