Security: document SECURITY DEFINER interaction with df.start()

[pinodeca]

Summary

df.start() captures the calling identity via GetUserId(), which returns current_user. In a SECURITY DEFINER context, this is the function owner, not the actual caller. This means all SQL nodes in the workflow execute as the definer's identity — the caller controls the fut argument content, so they can execute arbitrary SQL as the definer.

Example

-- Admin creates helpful wrapper
CREATE FUNCTION run_report(q TEXT) RETURNS TEXT
LANGUAGE SQL SECURITY DEFINER AS $$
    SELECT df.start(df.sql(q), 'report');
$$;
GRANT EXECUTE ON FUNCTION run_report TO reporting_role;

-- Attacker (reporting_role) escalates:
SELECT run_report('DROP TABLE admin_secrets');
-- SQL executes as the admin who owns run_report

Assessment

This is by-design PostgreSQL SECURITY DEFINER semantics, and the test suite validates it (tests/e2e/sql/13_user_isolation.sql, Test 6b). However, it is easy for administrators to create dangerous wrappers without realizing the implication.

Recommended Actions

1. Add a prominent warning in USER_GUIDE.md about SECURITY DEFINER interaction with df.start().
2. Consider adding a df.start() option or GUC that forces session_user capture instead of current_user.

Context

• Security review Finding 5 (severity: Medium)
• Affected component: src/dsl.rs, function start()

[pinodeca]

Decision update for PR #185: we are keeping this as a documentation-only fix.

df.start() will continue to capture the effective role (current_user) at submission time. Inside a PostgreSQL SECURITY DEFINER function, that effective role is the function owner, so workflows submitted from such wrappers run as the definer. This is standard PostgreSQL behavior and is already covered by the user-isolation tests.

We are not adding a df.start() option or GUC to capture session_user / outer invoker identity at this time. There is not currently a feature request requiring durable work submitted from a SECURITY DEFINER wrapper to run as the caller, and the semantics around current_user, session_user, SET ROLE, login roles, group roles, and nested SECURITY DEFINER calls need a separate design discussion before introducing runtime behavior.

PR #185 now documents the risk and recommended mitigations: avoid untrusted SQL or futures in SECURITY DEFINER wrappers, prefer SECURITY INVOKER where possible, use fixed server-side workflow definitions, and validate arguments explicitly.