<!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.30 2001/11/28 20:49:09 petere Exp $ -->

<!--

$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.31 2001/12/27 21:37:34 tgl Exp $

-->

<chapter id="client-authentication">

<title>Client Authentication</title>

<sect1 id="auth-methods">

<title>Authentication methods</title>

<para>

The following describes the authentication methods in detail.

The following describes the authentication methods inmoredetail.

</para>

<sect2 id="auth-trust">

<title>Trust authentication</title>

<para>

When <literal>trust</> authentication is specified,

<productname>PostgreSQL</productname> 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.

</para>

<para>

<literal>trust</> authentication is appropriate and very convenient

for local connections on a single-user workstation. It is usually

<emphasis>not</> appropriate by itself on a multi-user machine.

However, you may be able to use <literal>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

<varname>unix_socket_permissions</varname> (and possibly

<varname>unix_socket_group</varname>) in <filename>postgresql.conf</>,

as described in <xref linkend="runtime-config-general">. Or you could

set <varname>unix_socket_directory</varname> to place the socket file

in a suitably restricted directory.

</para>

<para>

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 <literal>host ...

127.0.0.1 ...</> line from <filename>pg_hba.conf</>, or change it to a

non-<literal>trust</> authentication method.

</para>

<para>

<literal>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 <filename>pg_hba.conf</> lines that specify

<literal>trust</>. It is seldom reasonable to use <literal>trust</>

for any TCP connections other than those from localhost (127.0.0.1).

</para>

</sect2>

<sect2 id="auth-password">

<title>Password authentication</title>

<primary>MD5</>

</indexterm>

<para>

Password-based authentication methods include <literal>md5</>,

<literal>crypt</>, and <literal>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 <quote>sniffing</>

attacks then <literal>md5</> is preferred, with <literal>crypt</> a

second choice if you must support obsolete clients. Plain

<literal>password</> should especially be avoided for connections over

the open Internet (unless you use SSL, SSH, or other communications

security wrappers around the connection).

</para>

<para>

<productname>PostgreSQL</productname> database passwords are separate from

operating system user passwords. Ordinarily, the password for each

On systems supporting <symbol>SO_PEERCRED</symbol> 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 forlocal connections onsuch a system.

</para>

<para>

<!--

$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.99 2001/11/28 20:49:10 petere Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.100 2001/12/27 21:37:34 tgl Exp $

-->

<Chapter Id="runtime">

through a single instance of a running database server. After

initialization, a database cluster will contain one database named

<literal>template1</literal>. As the name suggests, this will be used

as a template foranysubsequently createddatabase; it should not be

as a template for subsequently createddatabases; it should not be

used for actual work.

</para>

<para>

In file system terms, a database cluster will be a single directory

under which all data will be stored. We call this the <firstterm>data

directory</firstterm> or <firstterm>data area</firstterm>. 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

<filename>/usr/local/pgsql/data</filename> or

<filename>/var/lib/pgsql/data</filename> are popular. To initialize a

<screen>

<prompt>$</> <userinput>initdb -D /usr/local/pgsql/data</userinput>

</screen>

Note that you must execute this command while being loggedin to

Note that you must execute this command while being loggedinto

the <productname>PostgreSQL</productname> user account, which is described in the previous

section.

</para>

<para>

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. <command>initdb</command> therefore revokes access

permissions from everyone but the <productname>PostgreSQL</productname> user account.

</para>

<para>

However, while the directory contents are secure, the default

<filename>pg_hba.conf</filename> authentication of

<literal>trust</literal> allows any local user tobecomethe

superuserandconnect to the database. If you don't trustyour local

users, we recommend you usethe<command>initdb</command> option

<filename>pg_hba.conf</filename> authenticationmethodof

<literal>trust</literal> allows any local user toconnect tothe database

andeven become the database superuser. If you don't trustother local

users, we recommend you use <command>initdb</command>'s option

<option>-W</option> or <option>--pwprompt</option> to assign a

password to the superuser and modify your

<filename>pg_hba.conf</filename> accordingly. (Another option:

Your operating system may support <literal>ident</literal> for

local connections.)

password to the database superuser. After <command>initdb</command>,

modify <filename>pg_hba.conf</filename> to use <literal>md5</> or

<literal>password</>, instead of <literal>trust</>, authentication

<emphasis>before</> you first start the postmaster. (Other, possibly

more convenient approaches include using <literal>ident</literal>

authentication or filesystem permissions to restrict connections. See

<xref linkend="client-authentication"> for more information.)

</para>

<para>

$ <userinput>postmaster -D /usr/local/pgsql/data</userinput>

</screen>

which will leave the server running in the foreground. This must

again be done while loggedin to the <productname>PostgreSQL</productname> user account. Without

again be done while loggedinto the <productname>PostgreSQL</productname> user account. Without

a <option>-D</option>, the server will try to use the data

directory in the environment variable <envar>PGDATA</envar>; if

neither of these works it will fail.

<para>

On <productname>Linux</productname>

<filename>/proc/sys/fs/file-max</filename> determines the

maximum number of files that the kernel willallocate. It can

maximum number ofopenfiles that the kernel willsupport. It can

be changed by writing a different number into the file or by

adding an assignment in <filename>/etc/sysctl.conf</filename>.

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.

</para>

<para>

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

can set <productname>PostgreSQL</productname>'s

<varname>max_files_per_process</varname> configuration parameter

to limit its consumption of open files.

</para>

</sect2>

</sect1>