db-privilege

The sections below are generated from the CLI (methodology 0.3-draft, CLI 0.3.0); the same text is printed by sealmark explain db-privilege.

Probes

• backends SELECT usename FROM pg_stat_activity WHERE datname = 'sealmark_seed' AND pid <> ALL(<harness pids>), before and after each instance starts and answers one read core
• current-user SELECT current_user AS u, '<token>' AS t core
• role-attributes pg_roles.rolsuper and rolbypassrls, and pg_tables.tableowner for customers and orders, for every role seen core

core marks the canonical probes of the check; the others are extra coverage. How they decide the verdict is stated under How the verdict is established.

Settings and thresholds

Every check also takes checks.db-privilege.enabled and checks.db-privilege.severity; they are described once in the configuration reference.

This check has no numeric threshold.

How the verdict is established

• Scoring. advisory: reported with its verdict but not part of the score.

What to fix

Connect to the database as exactly the role in the {dsn} the server is given, on every connection (including metadata or admin pools), and use a role that is not a superuser, not BYPASSRLS and not the table owner. This check is advisory and not scored.

False positives

The harness supplies every credential, so 'superuser or table owner' is fixed by construction; the check asks whether the server used the credentials it was given. A server that opens an extra connection as another role (a metadata or admin pool) fails even if it never runs a query with it. Advisory: not scored.

False negatives

A connection pool outside the database hides the backends, and a server with no SQL tool that can read leaves nothing to ask: both are inconclusive, never a pass. A server that connects as the right role at start and switches later (SET ROLE) is not seen.