-
+
Client Authentication
Authentication methods
- The following describes the authentication methods in detail.
+ The following describes the authentication methods in more detail.
+
+
Trust authentication
+
+ When trust> authentication is specified,
+
PostgreSQL assumes that anyone who can
+ connect to the postmaster is authorized to access the database as
+ whatever database user he specifies (including the database superuser).
+ This method should only be used when there is adequate system-level
+ protection on connections to the postmaster port.
+
+
+ trust> authentication is appropriate and very convenient
+ for local connections on a single-user workstation. It is usually
+ not> appropriate by itself on a multi-user machine.
+ However, you may be able to use trust> even on a multi-user
+ machine, if you restrict access to the postmaster's socket file using
+ filesystem permissions. To do this, set the parameter
+ unix_socket_permissions (and possibly
+ unix_socket_group) in postgresql.conf>,
+ as described in . Or you could
+ set unix_socket_directory to place the socket file
+ in a suitably restricted directory.
+
+
+ Setting filesystem permissions only helps for Unix-socket connections.
+ Local TCP connections are not restricted by it; therefore, if you want
+ to use permissions for local security, remove the host ...
+ 127.0.0.1 ...> line from pg_hba.conf>, or change it to a
+ non-trust> authentication method.
+
+
+ trust> authentication is only suitable for TCP connections
+ if you trust every user on every machine that is allowed to connect
+ to the postmaster by the pg_hba.conf> lines that specify
+ trust>. It is seldom reasonable to use trust>
+ for any TCP connections other than those from localhost (127.0.0.1).
+
+
+
+
Password authentication
+ Password-based authentication methods include md5>,
+ crypt>, and password>. These methods operate
+ similarly except for the way that the password is sent across the
+ connection. If you are at all concerned about password sniffing>
+ attacks then md5> is preferred, with crypt> a
+ second choice if you must support obsolete clients. Plain
+ password> should especially be avoided for connections over
+ the open Internet (unless you use SSL, SSH, or other communications
+ security wrappers around the connection).
+
+
PostgreSQL database passwords are separate from
operating system user passwords. Ordinarily, the password for each
On systems supporting SO_PEERCRED requests for Unix-domain sockets,
ident authentication can also be applied to local connections. In this
case, no security risk is added by using ident authentication; indeed
- it is a preferable choice for such a system.
+ it is a preferable choice for local connections on such a system.
through a single instance of a running database server. After
initialization, a database cluster will contain one database named
template1. As the name suggests, this will be used
- as a template for any subsequently created database; it should not be
+ as a template for subsequently created databases; it should not be
used for actual work.
In file system terms, a database cluster will be a single directory
under which all data will be stored. We call this the data
directory or data area. It is
- completely up to you where you choose to store your data, there is no
+ completely up to you where you choose to store your data. There is no
default, although locations such as
/usr/local/pgsql/data or
/var/lib/pgsql/data are popular. To initialize a
$> initdb -D /usr/local/pgsql/data
- Note that you must execute this command while being logged in to
+ Note that you must execute this command while being logged into
the
PostgreSQL user account, which is described in the previous
section.
Because the data directory contains all the data stored in the
- database it is essential that it be well secured from unauthorized
+ database, it is essential that it be well secured from unauthorized
access. initdb therefore revokes access
permissions from everyone but the
PostgreSQL user account.
However, while the directory contents are secure, the default
- pg_hba.conf authentication of
- trust allows any local user to become the
- superuser and connect to the database. If you don't trust your local
- users, we recommend you use the initdb option
+ pg_hba.conf authentication method of
+ trust allows any local user to connect to the database
+ and even become the database superuser. If you don't trust other local
+ users, we recommend you use initdb's option
or to assign a
- password to the superuser and modify your
- pg_hba.conf accordingly. (Another option:
- Your operating system may support ident for
- local connections.)
+ password to the database superuser. After initdb,
+ modify pg_hba.conf to use md5> or
+ password>, instead of trust>, authentication
+ before> you first start the postmaster. (Other, possibly
+ more convenient approaches include using ident
+ authentication or filesystem permissions to restrict connections. See
+ for more information.)
$ postmaster -D /usr/local/pgsql/data
which will leave the server running in the foreground. This must
- again be done while logged in
to the
PostgreSQL user account. Without
+ again be done while logged into the
PostgreSQL user account. Without
a , the server will try to use the data
directory in the environment variable PGDATA; if
neither of these works it will fail.
/proc/sys/fs/file-max determines the
- maximum number of files that the kernel will allocate. It can
+ maximum number of open files that the kernel will support. It can
be changed by writing a different number into the file or by
adding an assignment in /etc/sysctl.conf.
The maximum limit of files per process is fixed at the time the
is perhaps what you want, but on dedicated servers you may want to
raise this limit.
+
+ On the other side of the coin, some systems allow individual
+ processes to open large numbers of files; if more than a few processes
+ do so then the system-wide limit can easily be exceeded. If you find
+ this happening, and don't want to alter the system-wide limit, you
+ max_files_per_process configuration parameter
+ to limit its consumption of open files.
+