|
1 | 1 | .\" This is -*-nroff-*-
|
2 |
| -.\" $Header: /cvsroot/pgsql/src/man/Attic/pg_hba.conf.5,v 1.3 1997/08/26 17:30:03 momjian Exp $ |
3 |
| -.TH pg_hba.conf 5 11/04/96 Postgres Postgres |
| 2 | +.\" $Header: /cvsroot/pgsql/src/man/Attic/pg_hba.conf.5,v 1.4 1998/01/27 03:25:14 scrappy Exp $ |
| 3 | +.TH pg_hba.conf 5 1/26/98 PostgreSQL PostgreSQL |
4 | 4 | .SH NAME
|
5 | 5 | $PGDATA/pg_hba.conf
|
6 | 6 | .SH DESCRIPTION
|
7 |
| -"Host-based access control" is the name for the basic controls Postgres |
8 |
| -exercises on what clients are allowed to access a database system. |
9 |
| -It is called that because one of the factors that can control access is |
10 |
| -from what host the client is connecting. |
| 7 | +"Host-based access control" is the name for the basic controls PostgreSQL |
| 8 | +exercises on what clients are allowed to access a database and how |
| 9 | +the users on those clients must authenticate themselves. |
11 | 10 | .PP
|
12 |
| -Each database system contains a file named "pg_hba.conf", in its PGDATA |
13 |
| -directory, that controls who can connect to that database system. |
| 11 | +Each database system contains a file named "pg_hba.conf", in its $PGDATA |
| 12 | +directory, that controls who can connect to each database. |
14 | 13 | .PP
|
15 |
| -The exact format of the pg_hba.conf file is described in the comments at |
16 |
| -the top of the sample file pg_hba.conf.sample, which resides in the |
17 |
| -the PostgreSQL "lib" sub-directory of the main postgres directory. |
| 14 | +Every client that wants to access to a database |
| 15 | +.IR must |
| 16 | +be covered by one of |
| 17 | +the entries in pg_hba.conf. Otherwise all attempted connections from that |
| 18 | +client will be rejected with a "User authentication failed" error message. |
| 19 | +.PP |
| 20 | +The general format of the pg_hba.conf file is of a set of records, one per |
| 21 | +line. Blank lines and lines beginning with '#' are ignored. A record is |
| 22 | +made up of a number of fields which are separated by spaces and/or tabs. |
| 23 | +.PP |
| 24 | +Connections from clients can be made using UNIX domain sockets or Internet |
| 25 | +domain sockets (ie. TCP/IP). Connections made using UNIX domain sockets |
| 26 | +are controlled using records of the following format. |
| 27 | +.PP |
| 28 | +local <database> <authentication method> |
| 29 | +.PP |
| 30 | +<database> specifies the database that this record applies to. The value |
| 31 | +.IR all |
| 32 | +specifies that it applies to all databases. <authentication method> |
| 33 | +specifies the method a user must use to authenticate themselves when |
| 34 | +connecting to that database using UNIX domain sockets. The different methods |
| 35 | +are described below. |
| 36 | +.PP |
| 37 | +Connections made using Internet domain sockets are controlled using records |
| 38 | +of the following format. |
| 39 | +.PP |
| 40 | +host <database> <TCP/IP address> <TCP/IP mask> <authentication method> |
| 41 | +.PP |
| 42 | +The <TCP/IP mask> is logically anded to both the specified <TCP/IP address> |
| 43 | +and the TCP/IP address |
| 44 | +of the connecting client. If the two values that result are equal then the |
| 45 | +record is used for this connection. If a connection matches more than one |
| 46 | +record then the earliest one in the file is used. Both the <TCP/IP address> |
| 47 | +and the <TCP/IP mask> are specified in dotted decimal notation. |
| 48 | +.PP |
| 49 | +If a connection fails to match any record then the |
| 50 | +.IR reject |
| 51 | +authentication method is applied (see below). |
| 52 | +.SH "AUTHENTICATION METHODS" |
| 53 | +The following authentication methods are supported for both UNIX and TCP/IP |
| 54 | +domain sockets. |
| 55 | +.PP |
| 56 | +.IR trust |
| 57 | +- the connection is allowed unconditionally. |
| 58 | +.PP |
| 59 | +.IR reject |
| 60 | +- the connection is rejected unconditionally. |
| 61 | +.PP |
| 62 | +.IR crypt |
| 63 | +- the client is asked for a password for the user. This is sent encrypted |
| 64 | +(using crypt(3)) and compared against the password held in the pg_user table. |
| 65 | +If the passwords match, the connection is allowed. |
| 66 | +.PP |
| 67 | +.IR password |
| 68 | +- the client is asked for a password for the user. This is sent in clear |
| 69 | +and compared against the password held in the pg_user table. |
| 70 | +If the passwords match, the connection is allowed. An optional password file |
| 71 | +may be specified after the |
| 72 | +.IR password |
| 73 | +keyword which is used to match the supplied password rather than the pg_user |
| 74 | +table. See pg_passwd(1). |
| 75 | +.PP |
| 76 | +The following authentication methods are supported for TCP/IP |
| 77 | +domain sockets only. |
| 78 | +.PP |
| 79 | +.IR krb4 |
| 80 | +- Kerberos V4 is used to authenticate the user. |
| 81 | +.PP |
| 82 | +.IR krb5 |
| 83 | +- Kerberos V5 is used to authenticate the user. |
| 84 | +.PP |
| 85 | +.IR ident |
| 86 | +- the ident server on the client is used to authenticate the user (RFC 1413). |
| 87 | +An optional map name may be specified after the |
| 88 | +.IR ident |
| 89 | +keyword which allows ident user names to be mapped onto PostgreSQL user names. |
| 90 | +Maps are held in the file $PGDATA/pg_ident.conf. |
| 91 | +.SH EXAMPLES |
| 92 | + |
| 93 | +# Trust any connection via UNIX domain sockets. |
| 94 | + |
| 95 | +local trust |
| 96 | + |
| 97 | +# Trust any connection via TCP/IP from this machine. |
| 98 | + |
| 99 | +host all 127.0.0.1 255.255.255.255 trust |
| 100 | + |
| 101 | +# We don't like this machine. |
| 102 | + |
| 103 | +host all 192.168.0.10 255.255.255.0 reject |
| 104 | + |
| 105 | +# This machine can't encrypt so we ask for passwords in clear. |
| 106 | + |
| 107 | +host all 192.168.0.3 255.255.255.0 password |
| 108 | + |
| 109 | +# The rest of this group of machines should provide encrypted passwords. |
| 110 | + |
| 111 | +host all 192.168.0.0 255.255.255.0 crypt |
18 | 112 |
|
19 | 113 | .SH "SEE ALSO"
|
20 | 114 | pgintro(1).
|
|
0 commit comments