Use PostgreSQL data and privileged program execution

Needs: Accepted connection/database role; COPY PROGRAM needs the corresponding server privilege and an executable OS context

Shell commands

# Baseline
psql -h TARGET -p PORT -U USER -d postgres

Client commands / example output

# Baseline
\conninfo
\l
\du
\dn
\dt *.*

SQL commands

-- Baseline
SELECT version(), current_user, session_user;
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles;

-- PostgreSQL variant — server file/program privilege boundary
SELECT pg_has_role(current_user, 'pg_read_server_files', 'member');
SELECT pg_has_role(current_user, 'pg_write_server_files', 'member');
SELECT pg_has_role(current_user, 'pg_execute_server_program', 'member');

Server-side COPY ... FROM/TO 'file' uses the PostgreSQL server's filesystem and service identity. COPY ... PROGRAM executes on the server and requires superuser or the corresponding predefined role. Client-side \copy reads/writes the client filesystem and is not the same primitive.

Failure cues: connection refusal/timeout is network or listener context; login rejection is authentication/context; an empty database list may be visibility limits; object denial is authorization. Query only bounded rows first. Never assume that reading application credentials or obtaining database admin implies OS execution.

Next action: identify application accounts, hashes/credentials, paths and linked systems; record the precise grant enabling any file or execution primitive; validate recovered credentials in the later credential block and re-enumerate after any identity change.

Verify → Separate returned rows, file operations and command execution; prove the actual operating-system identity for the latter.

If it fails → Role or OS permission failures require another allowed primitive, not a different spelling of the same denied operation. More detail ↓

If → then

A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
Needs: Artifact provenance and format; possible local/domain/application identity and compatible protocol
Confirmed SQL control plus database file, execution or impersonation privileges → Convert database rights into a file or operating-system effect
Needs: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer
A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Use PostgreSQL data and privileged program execution

USE WHEN: PostgreSQL access or an application connection string
STARTING ACCESS: A confirmed reachable application; anonymous context or one identified credential
RESULT: Database information or a verified privilege-backed OS effect

Recognize the clue

Authenticate to the observed database and inspect current/session identity and role attributes before program/file functions.

SELECT current_user,session_user,version();
SELECT rolname,rolsuper FROM pg_roles WHERE rolname=current_user;

SYNTHETIC EXAMPLE OUTPUT

current_user | session_user
APP_USER     | APP_USER
rolname      | rolsuper
APP_USER     | f

Means: An ordinary database role does not automatically have COPY PROGRAM or server-file access.

Confirm: Inspect effective role memberships and exact operation rights, then the database service's OS context.

After validation: The needed execution/file role and a usable consumer are established: select that documented operation.
Ruled out in this context: No superuser or required operation-specific privilege rules out the proposed program-execution route.
Still inconclusive: Unknown inherited role rights leave the operation unresolved; enumerate memberships before deciding.

Troubleshooting: Role or OS permission failures require another allowed primitive, not a different spelling of the same denied operation.

PostgreSQL variant — server file/program privilege boundary

Server-side COPY ... FROM/TO 'file' uses the PostgreSQL server's filesystem and service identity. COPY ... PROGRAM executes on the server and requires superuser or the corresponding predefined role. Client-side \copy reads/writes the client filesystem and is not the same primitive.

Failure cues: connection refusal/timeout is network or listener context; login rejection is authentication/context; an empty database list may be visibility limits; object denial is authorization. Query only bounded rows first. Never assume that reading application credentials or obtaining database admin implies OS execution.

Next action: identify application accounts, hashes/credentials, paths and linked systems; record the precise grant enabling any file or execution primitive; validate recovered credentials in the later credential block and re-enumerate after any identity change.

Why it works

SQL access does not imply server superuser. File/program functions execute as the database service and are gated by database roles and OS permissions.

Worked example · hypothetical

Observation: a database role can read application tables. Test: inspect role attributes. Illustrative output: rolsuper is false and program-execution rights are absent. Interpretation: recover useful data without treating SQL access as a shell.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗