Security: restrict df.metrics() to user-scoped data or superusers

[pinodeca]

Summary

df.metrics() queries the duroxide store directly for system-wide aggregate metrics without any RLS filtering. Unlike df.list_instances() (which filters through RLS), any user who can call df.metrics() sees total instance counts, running/completed/failed counts, and total execution/event counts across all users.

Impact

Information disclosure about other users' workflow activity patterns. While no row-level data is leaked, aggregate counts reveal system-wide usage.

Recommended Actions

Either:

1. Restrict df.metrics() to superusers — remove it from the functions granted by df.grant_usage(), or
2. Filter metrics to the calling user's own instances — query through RLS-filtered views instead of the duroxide store directly.

Context

• Security review Finding 6 (severity: Low)
• Affected component: src/monitoring.rs, function metrics()

[pinodeca]

Decision: manage df.metrics() access via explicit EXECUTE grants

This issue offered two options — restrict df.metrics() to superusers, or filter it to the caller's own instances. We're going with a third, more flexible option in #184: gate df.metrics() behind ordinary PostgreSQL function privileges rather than tying it to the superuser bit or rewriting it to be user-scoped.

How it works:

• Fresh installs REVOKE EXECUTE ON FUNCTION df.metrics() FROM PUBLIC, so it is private by default.
• df.grant_usage() does not grant df.metrics() — granting ordinary usage no longer exposes cluster-wide metrics.
• An admin explicitly runs GRANT EXECUTE ON FUNCTION df.metrics() TO <role> for any role that should see system-wide activity. This is deliberately not limited to superusers, so operators can delegate metrics visibility to a monitoring role without handing out superuser.
• df.revoke_usage() also revokes df.metrics(), so an admin can revoke and then re-grant ordinary usage in a way that omits metrics — and clean up installs that granted it under older grant_usage() bodies.

Rationale:

• Keeps the aggregate counts available where genuinely needed (e.g. monitoring/ops roles) without leaking them to every grant_usage() user.
• Avoids a hard-coded superuser-only runtime check, which is coarser than necessary and not configurable.
• Avoids re-scoping the metric semantics; df.metrics() remains a true cluster-wide aggregate, which is its purpose.

Upgrade behavior: the 0.2.3→0.2.4 upgrade applies the same REVOKE ... FROM PUBLIC and updated df.revoke_usage() body, but does not retroactively revoke existing explicit grants. Admins who previously exposed it via grant_usage() can run df.revoke_usage(<role>) and re-grant ordinary usage to remove metrics access.

Tracked and implemented in #184.