Commit 0bba6bdb authored by Bruce Momjian's avatar Bruce Momjian

Improve wording of authentication files.

parent 2c5aa2ac
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pg_passwd.sgml,v 1.6 2001/02/20 01:16:49 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pg_passwd.sgml,v 1.7 2001/06/18 16:11:30 momjian Exp $
Postgres documentation Postgres documentation
--> -->
...@@ -16,7 +16,7 @@ Postgres documentation ...@@ -16,7 +16,7 @@ Postgres documentation
<refnamediv> <refnamediv>
<refname>pg_passwd</refname> <refname>pg_passwd</refname>
<refpurpose>Manipulate a text password file</refpurpose> <refpurpose>Manipulate a secondary password file</refpurpose>
</refnamediv> </refnamediv>
<refsynopsisdiv> <refsynopsisdiv>
...@@ -29,30 +29,28 @@ Postgres documentation ...@@ -29,30 +29,28 @@ Postgres documentation
<refsect1 id="app-pg-passwd-description"> <refsect1 id="app-pg-passwd-description">
<title>Description</title> <title>Description</title>
<para> <para>
<application>pg_passwd</application> is a tool to manipulate a flat <application>pg_passwd</application> is a tool for manipulating flat
text password file for the purpose of using that file to control text password files. These files can control client authentication of
client authentication of the the <productname>PostgreSQL</productname> server. More information
<productname>PostgreSQL</productname> server. More information
about setting up this authentication mechanism can be found in the about setting up this authentication mechanism can be found in the
<citetitle>Administrator's Guide</citetitle>. <citetitle>Administrator's Guide</citetitle>.
</para> </para>
<para> <para>
The form of a text password file is one entry per line; the fields The format of a text password file is one entry per line; the fields
of each entry are separated by colons. The first field is the user of each entry are separated by colons. The first field is the user
name, the second field is the encrypted password. Other fields are name, the second field is the encrypted password. Other fields are
ignored (to allow password files to be shared between applications ignored (to allow password files to be shared between applications
that use similar formats). The functionality of the that use similar formats). <application>pg_passwd</application>
<application>pg_passwd</application> utility is to enable a user to enables users to interactively add entries to such a file, to alter
interactively add entries to such a file, to alter passwords of passwords of existing entries, and to encrypt such passwords.
existing entries, and to take care of encrypting the passwords.
</para> </para>
<para> <para>
Supply the name of the password file as argument to the <application>pg_passwd</application> Supply the name of the password file as argument to the
command. To be of use for client authentication the file needs to <application>pg_passwd</application> command. To be used by
be located in the server's data directory, and the base name of PostgreSQL, the file needs to be located in the server's data
the file needs to be specified in the directory, and the base name of the file needs to be specified in the
<filename>pg_hba.conf</filename> access control file. <filename>pg_hba.conf</filename> access control file.
<screen> <screen>
...@@ -90,11 +88,11 @@ host mydb 133.65.96.250 255.255.255.255 password passwords ...@@ -90,11 +88,11 @@ host mydb 133.65.96.250 255.255.255.255 password passwords
<note> <note>
<para> <para>
It is also useful to have entries in a password file with an empty It is also useful to have entries in a password file with empty
password field. (This is different from an empty password.) password fields. (This is different from an empty password.) Such
These entries cannot be managed by entries allow you to restrict users who can access the system. These
<application>pg_passwd</application>, but it is always possible to entries cannot be managed by <application>pg_passwd</application>,
edit password files manually. but you can edit password files manually.
</para> </para>
</note> </note>
</refsect1> </refsect1>
......
...@@ -2,7 +2,7 @@ ...@@ -2,7 +2,7 @@
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California * Portions Copyright (c) 1994, Regents of the University of California
* *
* $Id: password.c,v 1.36 2001/03/22 03:59:30 momjian Exp $ * $Id: password.c,v 1.37 2001/06/18 16:11:30 momjian Exp $
* *
*/ */
...@@ -76,9 +76,11 @@ verify_password(const Port *port, const char *user, const char *password) ...@@ -76,9 +76,11 @@ verify_password(const Port *port, const char *user, const char *password)
FreeFile(pw_file); FreeFile(pw_file);
/* /*
* If the password is empty of "+" then we use the regular * If the password is empty or "+" then we use the regular
* pg_shadow passwords. If we use crypt then we have to use * pg_shadow passwords. If we use crypt then we have to use
* pg_shadow passwords no matter what. * pg_shadow passwords no matter what. This is because
* the current code needs non-encrypted passwords to
* encrypt with a random salt.
*/ */
if (port->auth_method == uaCrypt if (port->auth_method == uaCrypt
|| test_pw == NULL || test_pw[0] == '\0' || test_pw == NULL || test_pw[0] == '\0'
......
# #
# PostgreSQL HOST ACCESS CONTROL FILE # PostgreSQL HOST-BASED ACCESS (HBA) CONTROL FILE
# #
# #
# This file controls what hosts are allowed to connect to what databases # This file controls:
# and specifies how users on a particular host are identified. It is read
# by the PostgreSQL postmaster each time a host tries to make a connection
# to a database.
# #
# Each line (terminated by a newline character) is a record. A record # o which hosts are allowed to connect
# cannot be continued across two lines. # o how users are authenticated on each host
# o databases accessible by each host
# #
# There are 3 kinds of records: # It is read by the PostgreSQL postmaster each time a host tries to make a
# 1) comment: Starts with #. # connection to a database.
# 2) empty: Contains nothing excepting spaces and tabs.
# 3) record: anything else.
# Only record lines are significant.
# #
# A record consists of tokens separated by spaces or tabs. Spaces and # Each line is a new record. Records cannot be continued across multiple
# tabs at the beginning and end of a record are ignored, as are extra # lines. Lines beginning with # (comments) and blank lines are ignored. A
# spaces and tabs between two tokens. # record consists of tokens separated by multiple spaces or tabs.
# #
# The first token in a record is the record type. The interpretation of # The first token of a record indicates its type. The remainder of the
# the rest of the record depends on the record type. # record is interpreted based on its type.
# Record type "host"
# ------------------
# #
# This record identifies a set of network hosts that are permitted to # Record Types
# connect to databases via IP connections. No hosts are permitted to connect # ============
# over IP except as specified by a "host" record. #
# There are three types of records:
#
# o host
# o hostssl
# o local
#
# host
# ----
#
# This record identifies the networked hosts that are permitted to connect
# via IP connections.
# #
# Format: # Format:
# #
# host DBNAME IP_ADDRESS ADDRESS_MASK AUTHTYPE [AUTH_ARGUMENT] # host DBNAME IP_ADDRESS ADDRESS_MASK AUTH_TYPE [AUTH_ARGUMENT]
#
# DBNAME can be:
# #
# DBNAME is the name of a PostgreSQL database, or "all" to indicate all # o the name of a PostgreSQL database
# databases, or "sameuser" to restrict a user's access to a database with # o "all" to indicate all databases
# the same name as the user. # o "sameuser" to allow access only to databases with the same
# name as the connecting user
# #
# IP_ADDRESS and ADDRESS_MASK are a standard dotted decimal IP address # IP_ADDRESS and ADDRESS_MASK are standard dotted decimal IP address and
# and mask to identify a set of hosts. These hosts are allowed to connect # mask values. IP addresses can only be specified numerically, not as
# to the database(s) identified by DBNAME. Note that the IP address must # domain or host names.
# be specified numerically, not as a domain name.
# #
# AUTHTYPE and AUTH_ARGUMENT are described below. # AUTH_TYPE and AUTH_ARGUMENT are described below.
# #
# There can be multiple "host" records, possibly with overlapping sets of # There can be multiple "host" records, possibly with overlapping sets of
# host addresses. The postmaster scans to find the first entry that matches # host addresses. The postmaster finds the first entry that matches the
# the connecting host IP address and the requested database name. This # connecting host IP address and the requested database name. If no entry
# entry's AUTHTYPE will then be used to verify or reject the connection. # matches the database/hostname combination, the connection is rejected.
# If no entry matches the host+database, the connection is rejected. #
# Record type "hostssl"
# ---------------------
# #
# The format of this record is identical to that of "host". # hostssl
# -------
#
# The format of this record is identical to "host".
# #
# This record identifies a set of network hosts that are permitted to # This record identifies a set of network hosts that are permitted to
# connect to databases over secure SSL IP connections. Note that a "host" # connect to databases over secure SSL IP connections. Note that a "host"
# record will also allow SSL connections; write "hostssl" if you want to # record will also allow SSL connections. "hostssl" forces these
# accept *only* SSL-secured connections from this host or hosts. # hosts to use *only* SSL-secured connections.
# #
# This keyword is only available if the server was compiled with SSL # This keyword is only available if the server was compiled with SSL
# support enabled. # support enabled.
#
#
# Record type "local" # local
# ------------------ # -----
# #
# This record identifies the authentication to use when connecting to # This record identifies the authentication to use when connecting to
# the server via a local UNIX socket. UNIX-socket connections will be # the server via a local UNIX domain socket. UNIX-socket connections are
# allowed only if this record type appears. # allowed only if this record type appears.
# #
# Format: # Format:
# #
# local DBNAME AUTHTYPE [AUTH_ARGUMENT] # local DBNAME AUTH_TYPE [AUTH_ARGUMENT]
# #
# The format is the same as that of the "host" record type except that # This format is identical to the "host" record type except the IP_ADDRESS
# the IP_ADDRESS and ADDRESS_MASK are omitted. # and ADDRESS_MASK fields are omitted.
# #
# As with "host" records, the first "local" record matching the requested # As with "host" records, the first "local" record matching the requested
# database name controls whether the connection is allowed. # database name is used.
# Authentication Types (AUTHTYPE)
# -------------------------------
# #
# AUTHTYPE is a keyword indicating the method used to authenticate the
# user, i.e. to determine that the user is authorized to connect under
# the PostgreSQL username supplied in the connection request. A
# different AUTHTYPE can be specified for each record in the file.
# #
# trust: No authentication is done. Trust that the user has the
# authority to use whatever username he specifies.
# #
# password: Authentication is done by matching a password supplied # Authentication Types (AUTH_TYPE)
# in clear by the host. If AUTH_ARGUMENT is specified then # ================================
# the password is compared with the user's entry in that #
# file (in the $PGDATA directory). These per-host password # AUTH_TYPE indicates the method used to authenticate users. The username
# files can be maintained with the pg_passwd(1) utility. # is specified in the connection request. A different AUTH_TYPE can be
# If no AUTH_ARGUMENT appears then the password is compared # specified for each record in the file.
# with the user's entry in the pg_shadow table.
# #
# crypt: Same as 'password', but authentication is done by # trust: No authentication is done. Any valid username is accepted,
# encrypting the password sent over the network. # including the PostgreSQL superuser. This option should
# be use only for machines where all users are truested.
#
# password: Authentication is done by matching a password supplied
# in clear by the host. If no AUTH_ARGUMENT is used, the
# password is compared with the user's entry in the
# pg_shadow table.
#
# If AUTH_ARGUMENT is specified, the username is looked up
# in that file in the $PGDATA directory. If the username
# exists but there is no password, the password is looked
# up in pg_shadow. If a password exists in the file, it is
# it used instead. These secondary files allow fine-grained
# control over who can access which databases and whether
# a non-default passwords are required. The same file can be
# used in multiple records for easier administration.
# Password files can be maintained with the pg_passwd(1)
# utility. Remember, these passwords override pg_shadow
# passwords.
#
# crypt: Same as "password", but authentication is done by
# encrypting the password sent over the network. This is
# always preferable to "password" except for old clients
# that don't support "crypt". Also, crypt can use
# usernames stored in secondary password files but not
# secondary passwords.
# #
# ident: Authentication is done by the ident server on the remote # ident: Authentication is done by the ident server on the remote
# host, via the ident (RFC 1413) protocol. An AUTH_ARGUMENT # host. AUTH_ARGUMENT is required and maps names found in
# is required: it is a map name to be found in the # the $PGDATA/pg_ident.conf file. The connection is
# $PGDATA/pg_ident.conf file. The connection is accepted # accepted if the file contains an entry for this map
# if pg_ident.conf contains an entry for this map name with # name with the ident-supplied username and the requested
# the ident-supplied username and the requested PostgreSQL # PostgreSQL username. The special map name "sameuser"
# username. The special map name "sameuser" indicates an # indicates an implied map (not in pg_ident.conf)
# implied map (not sought in pg_ident.conf) that maps every # that maps each ident username to the identical
# ident username to the identical PostgreSQL username. # PostgreSQL username.
# #
# krb4: Kerberos V4 authentication is used. # krb4: Kerberos V4 authentication is used.
# #
# krb5: Kerberos V5 authentication is used. # krb5: Kerberos V5 authentication is used.
# #
# reject: Reject the connection. # reject: Reject the connection. This is used to reject certain hosts
# that are part of a network specified later in the file.
# To be effective, "reject" must appear before the later
# entries.
# #
# Local (UNIX socket) connections support only AUTHTYPEs "trust", # Local UNIX-domain socket connections support only the AUTH_TYPEs of
# "password", "crypt", and "reject". # "trust", "password", "crypt", and "reject".
# Examples
# --------
# #
# TYPE DATABASE IP_ADDRESS MASK AUTHTYPE MAP
# #
# Allow any user on the local system to connect to any
# database under any username, but only via an IP connection:
# #
# host all 127.0.0.1 255.255.255.255 trust # Examples
# ========
# #
# The same, over Unix-socket connections:
# #
# Allow any user on the local system to connect to any database under any
# username using Unix-domain sockets (the default for local connections):
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# local all trust # local all trust
# #
# The same using IP connections on the same machine:
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host all 127.0.0.1 255.255.255.255 trust
#
# Allow any user from any host with IP address 192.168.93.x to # Allow any user from any host with IP address 192.168.93.x to
# connect to database "template1" as the same username that ident on that # connect to database "template1" as the same username that ident reports
# host identifies him as (typically his Unix username): # for the connection (typically his Unix username):
# #
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host template1 192.168.93.0 255.255.255.0 ident sameuser # host template1 192.168.93.0 255.255.255.0 ident sameuser
# #
# Allow a user from host 192.168.12.10 to connect to database "template1" # Allow a user from host 192.168.12.10 to connect to database "template1"
# if the user's password in pg_shadow is correctly supplied: # if the user's password in pg_shadow is correctly supplied:
# #
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host template1 192.168.12.10 255.255.255.255 crypt # host template1 192.168.12.10 255.255.255.255 crypt
# #
# In the absence of preceding "host" lines, these two lines will reject # In the absence of preceding "host" lines, these two lines will reject
# all connection attempts from 192.168.54.1 (since that entry will be # all connection from 192.168.54.1 (since that entry will be matched
# matched first), but allow Kerberos V5-validated connections from anywhere # first), but allow Kerberos V5-validated connections from anywhere else
# else on the Internet. The zero mask means that no bits of the host IP # on the Internet. The zero mask means that no bits of the host IP address
# address are considered, so it matches any host: # are considered, so it matches any host:
#
# #
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host all 192.168.54.1 255.255.255.255 reject # host all 192.168.54.1 255.255.255.255 reject
# host all 0.0.0.0 0.0.0.0 krb5 # host all 0.0.0.0 0.0.0.0 krb5
# #
# Allow users from 192.168.x.x hosts to connect to any database, if they # Allow users from 192.168.x.x hosts to connect to any database if they
# pass the ident check. If, for example, ident says the user is "bryanh" # pass the ident check. For example, if ident says the user is "james" and
# and he requests to connect as PostgreSQL user "guest1", the connection # he requests to connect as PostgreSQL user "guest", the connection is
# is allowed if there is an entry in pg_ident.conf for map "omicron" that # allowed if there is an entry in $PGDATA/pg_ident.conf with map name
# says "bryanh" is allowed to connect as "guest1": # "phoenix" that says "james" is allowed to connect as "guest":
# #
# host all 192.168.0.0 255.255.0.0 ident omicron # TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host all 192.168.0.0 255.255.0.0 ident phoenix
#
# See $PGDATA/pg_ident.conf for more information on Ident maps.
# #
# Put your actual configuration here # Put your actual configuration here
# ---------------------------------- # ==================================
#
# This default configuration allows any local user to connect as any # This default configuration allows any local user to connect with any
# PostgreSQL username, over either UNIX domain sockets or IP: # PostgreSQL username, over either UNIX domain sockets or IP:
#
# If you want to allow non-local connections, you will need to add more
# "host" records. Also, remember IP connections are only enabled if you
# start the postmaster with the -i option.
#
# CAUTION: if you are on a multiple-user machine, the default
# configuration is probably too liberal for you. Change it to use
# something other than "trust" authentication.
#
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
local all trust local all trust
host all 127.0.0.1 255.255.255.255 trust host all 127.0.0.1 255.255.255.255 trust
# If you want to allow non-local connections, you will need to add more
# "host" records (and don't forget to start the postmaster with "-i"!).
# CAUTION: if you are on a multiple-user machine, the above default
# configuration is probably too liberal for you --- change it to use
# something other than "trust" authentication.
# This is the pg_ident.conf file, which is used with Postgres ident-based #
# authentication (a subtype of host-based authentication). # PostgreSQL IDENT-BASED AUTHENTICATION MAPS
#
# This is a table of ident usernames (typically Unix usernames) and # This file controls PostgreSQL ident-based authentication. It maps ident
# their corresponding Postgres usernames. For example, user "bryanh" on # usernames (typically Unix usernames) to their corresponding PostgreSQL
# some particular remote system may equate to Postgres user "guest1". # usernames. Entries are grouped by map name. Each record consists of
# three fields:
# This file contains multiple maps. Each has a name. The pg_hba.conf #
# file determines what connections relate to this file and for those that # o map name
# do, which map to use. # o ident username
# o PostgreSQL username
# Each record consists of 3 tokens: #
# # For example, the following entry equates user "james" on a remote system
# 1) map name # to PostgreSQL user "guest" in the map named "phoenix":
# 2) ident username #
# 3) Postgres username # MAP IDENT PGUSERNAME
# phoenix james guest
# Note that it is possible for one user to map to multiple Postgres usernames. #
# A user always has to specify when he connects what Postgres username he is # "phoenix" can now be used by an "ident" record in $DATA/pg_hba.conf.
# using. This file is only used to validate that selection. #
# Multiple maps may be specified in this file and used by pg_hba.conf.
# If you just need a one-to-one correspondence between usernames reported #
# by ident and Postgres usernames, you don't need this file. Instead use # Note that it is possible for a remote user to map to multiple PostgreSQL
# the special map name "sameuser" in pg_hba.conf. # usernames. The PostgreSQL username specified at connection time controls
# which one is used.
#MAP IDENT POSTGRES USERNAME #
# If all ident usernames and PostgreSQL usernames are the same, you don't
#testmap robert bob # need this file. Instead, use the special map name "sameuser" in
#testmap lucy lucy # pg_hba.conf.
#
# MAP IDENT PGUSERNAME
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment