Chapter 28. Security

Database security is addressed at several levels:

• Data base file protection. All files stored within the database are protected from reading by any account other than the Postgres superuser account.

• Connections from a client to the database server are, by default, allowed only via a local Unix socket, not via TCP/IP sockets. The backend must be started with the -i option to allow non-local clients to connect.

• Client connections can be restricted by IP address and/or user name via the pg_hba.conf file in PG_DATA.

• Client connections may be authenticated vi other external packages.

• Each user in Postgres is assigned a username and (optionally) a password. By default, users do not have write access to databases they did not create.

• Users may be assigned to groups, and table access may be restricted based on group privileges.

User Authentication

Authentication is the process by which the backend server and postmaster ensure that the user requesting access to data is in fact who he/she claims to be. All users who invoke Postgres are checked against the contents of the pg_user class to ensure that they are authorized to do so. However, verification of the user's actual identity is performed in a variety of ways:

From the user shell

A backend server started from a user shell notes the user's (effective) user-id before performing a setuid to the user-id of user postgres. The effective user-id is used as the basis for access control checks. No other authentication is conducted.

From the network

If the Postgres system is built as distributed, access to the Internet TCP port of the postmaster process is available to anyone. The DBA configures the pg_hba.conf file in the PGDATA directory to specify what authentication system is to be used according to the host making the connection and which database it is connecting to. See pg_hba.conf(5) for a description of the authentication systems available. Of course, host-based authentication is not fool-proof in Unix, either. It is possible for determined intruders to also masquerade the origination host. Those security issues are beyond the scope of Postgres.

Host-Based Access Control

Host-based access control is the name for the basic controls PostgreSQL exercises on what clients are allowed to access a database and how the users on those clients must authenticate themselves.

Each database system contains a file named pg_hba.conf, in its PGDATA directory, which controls who can connect to each database.

Every client accessing a database must be covered by one of the entries in pg_hba.conf. Otherwise all attempted connections from that client will be rejected with a "User authentication failed" error message.

The general format of the pg_hba.conf file is of a set of records, one per line. Blank lines and lines beginning with a hash character ("#") are ignored. A record is made up of a number of fields which are separated by spaces and/or tabs.

Connections from clients can be made using Unix domain sockets or Internet domain sockets (ie. TCP/IP). Connections made using Unix domain sockets are controlled using records of the following format:

local database authentication method
     

Connections made using Internet domain sockets are controlled using records of the following format.

host database TCP/IP address TCP/IP mask authentication method
     

The TCP/IP address is logically anded to both the specified TCP/IP mask and the TCP/IP address of the connecting client. If the two resulting values are equal then the record is used for this connection. If a connection matches more than one record then the earliest one in the file is used. Both the TCP/IP address and the TCP/IP mask are specified in dotted decimal notation.

If a connection fails to match any record then the reject authentication method is applied (see below).

Authentication Methods

The following authentication methods are supported for both Unix and TCP/IP domain sockets:

trust

The connection is allowed unconditionally.

reject

The connection is rejected unconditionally.

crypt

The client is asked for a password for the user. This is sent encrypted (using crypt(3)) and compared against the password held in the pg_shadow table. If the passwords match, the connection is allowed.

password

The client is asked for a password for the user. This is sent in clear and compared against the password held in the pg_shadow table. If the passwords match, the connection is allowed. An optional password file may be specified after the password keyword which is used to match the supplied password rather than the pg_shadow table. See pg_passwd.

The following authentication methods are supported for TCP/IP domain sockets only:

krb4

Kerberos V4 is used to authenticate the user.

krb5

Kerberos V5 is used to authenticate the user.

ident

The ident server on the client is used to authenticate the user (RFC 1413). An optional map name may be specified after the ident keyword which allows ident user names to be mapped onto Postgres user names. Maps are held in the file $PGDATA/pg_ident.conf.

Examples

# Trust any connection via Unix domain sockets.
local	trust
# Trust any connection via TCP/IP from this machine.
host	all	127.0.0.1	255.255.255.255		trust
# We don't like this machine.
host	all	192.168.0.10	255.255.255.0		reject
# This machine can't encrypt so we ask for passwords in clear.
host	all	192.168.0.3	255.255.255.0		password
# The rest of this group of machines should provide encrypted passwords.
host	all	192.168.0.0	255.255.255.0		crypt