PostgreSQL Administrator's Guide
Prev | Chapter 8. Security | Next

# Functions and Rules

Functions and rules allow users to insert code into the backend server that other users may execute without knowing it. Hence, both mechanisms permit users to trojan horse others with relative impunity. The only real protection is tight control over who can define functions (e.g., write to relations with SQL fields) and rules. Audit trails and alerters on `pg_class`, `pg_user` and `pg_group` are also recommended.

## Functions

Functions written in any language except SQL run inside the backend server process with the permissions of the user `postgres` (the backend server runs with its real and effective user-id set to `postgres`. It is possible for users to change the server's internal data structures from inside of trusted functions. Hence, among many other things, such functions can circumvent any system access controls. This is an inherent problem with user-defined C functions.

## Rules

Like SQL functions, rules always run with the identity and permissions of the user who invoked the backend server.

## Caveats

There are no plans to explicitly support encrypted data inside of Postgres (though there is nothing to prevent users from encrypting data within user-defined functions). There are no plans to explicitly support encrypted network connections, either, pending a total rewrite of the frontend/backend protocol.

User names, group names and associated system identifiers (e.g., the contents of `pg_user.usesysid`) are assumed to be unique throughout a database. Unpredictable results may occur if they are not.

Prev | Home | Next
Access Control | Up | Secure TCP/IP Connection