Index: doc/src/sgml/client-auth.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v
retrieving revision 1.32
diff -c -r1.32 client-auth.sgml
*** doc/src/sgml/client-auth.sgml 20 Jan 2002 22:19:55 -0000 1.32
--- doc/src/sgml/client-auth.sgml 19 Mar 2002 05:51:45 -0000
***************
*** 10,23 ****
! When a client application connects to the database server, it specifies which
! PostgreSQL user name it wants to connect as,
! much the same way one logs into a Unix computer as a particular user.
! Within the SQL environment the active
! database user name determines access privileges to database
! objects -- see for more information
! about that. It is therefore obviously essential to restrict which
! database user name(s) a given client can connect as.
--- 10,23 ----
! When a client application connects to the database server, it
! specifies which PostgreSQL user name it
! wants to connect as, much the same way one logs into a Unix computer
! as a particular user. Within the SQL environment the active database
! user name determines access privileges to database objects -- see
! for more information about that. It is
! therefore obviously essential to restrict which database user name(s)
! a given client can connect as.
***************
*** 30,49 ****
PostgreSQL offers a number of different
! client authentication methods. The method to be used can be selected
! on the basis of (client) host and database; some authentication methods
! allow you to restrict by user name as well.
! PostgreSQL database user names are logically
separate from user names of the operating system in which the server
! runs. If all the users of a particular server also have accounts on
the server's machine, it makes sense to assign database user names
! that match their operating system user names. However, a server that accepts remote
! connections may have many users who have no local account, and in such
! cases there need be no connection between database user names and OS
! user names.
--- 30,48 ----
PostgreSQL offers a number of different
! client authentication methods. The method to be used can be selected
! on the basis of (client) host, database, and user.
! PostgreSQL user names are logically
separate from user names of the operating system in which the server
! runs. If all the users of a particular server also have accounts on
the server's machine, it makes sense to assign database user names
! that match their operating system user names. However, a server that
! accepts remote connections may have many users who have no local
! account, and in such cases there need be no connection between
! database user names and OS user names.
***************
*** 56,94 ****
Client authentication is controlled by the file
pg_hba.conf in the data directory, e.g.,
! /usr/local/pgsql/data/pg_hba.conf. (HBA stands
! for host-based authentication.) A default pg_hba.conf
! file is installed when the
! data area is initialized by initdb.
! 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. Records cannot be continued across lines.
Each record specifies a connection type, a client IP address range
! (if relevant for the connection type), a database name or names,
and the authentication method to be used for connections matching
! these parameters.
! The first record that matches the type, client address, and requested
! database name of a connection attempt is used to do the
! authentication step. There is no fall-through or
backup: if one record is chosen and the authentication
! fails, the following records are not considered. If no record
! matches, the access will be denied.
A record may have one of the three formats
! local databaseauthentication-method [ authentication-option ]
! host databaseIP-addressIP-maskauthentication-method [ authentication-option ]
! hostssl databaseIP-addressIP-maskauthentication-method [ authentication-option ]
The meaning of the fields is as follows:
--- 55,93 ----
Client authentication is controlled by the file
pg_hba.conf in the data directory, e.g.,
! /usr/local/pgsql/data/pg_hba.conf.
! (HBA stands for host-based authentication.) A default
! pg_hba.conf file is installed when the data area
! is initialized by initdb.
! The general format of the pg_hba.conf file is of
! a set of records, one per line. Blank lines are ignored, as is any
! text after the # comment character. A record is made
! up of a number of fields which are separated by spaces and/or tabs.
! Fields can contain white space if the field value is quoted. Records
! cannot be continued across lines.
Each record specifies a connection type, a client IP address range
! (if relevant for the connection type), a database name, a user name,
and the authentication method to be used for connections matching
! these parameters. The first record with a matching connection type,
! client address, requested database, and user name is used to peform
! authentication. There is no fall-through or
backup: if one record is chosen and the authentication
! fails, subsequent records are not considered. If no record matches,
! access is denied.
A record may have one of the three formats
! local databaseuserauthentication-method [ authentication-option ]
! host databaseuserIP-addressIP-maskauthentication-method
! hostssl databaseuserIP-addressIP-maskauthentication-method
The meaning of the fields is as follows:
***************
*** 97,103 ****
local
! This record pertains to connection attempts over Unix domain
sockets.
--- 96,102 ----
local
! This record applies to connection attempts using Unix domain
sockets.
***************
*** 107,116 ****
host
! This record pertains to connection attempts over TCP/IP
! networks. Note that TCP/IP connections are completely disabled
! unless the server is started with the switch or
! the equivalent configuration parameter is set.
--- 106,116 ----
host
! This record applied to connection attempts using TCP/IP networks.
! Note that TCP/IP connections are disabled unless the server is
! started with the option or the
! tcpip_socket postgresql.conf
! configuration parameter is enabled.
***************
*** 119,131 ****
hostssl
! This record pertains to connection attempts with SSL over
TCP/IP. To make use of this option the server must be
built with SSL support enabled. Furthermore, SSL must be
enabled with the
--- 119,131 ----
hostssl
! This record applies to connection attempts using SSL over
TCP/IP. To make use of this option the server must be
built with SSL support enabled. Furthermore, SSL must be
enabled with the
***************
*** 134,145 ****
database
! Specifies the database that this record applies to. The value
all specifies that it applies to all
databases, while the value sameuser identifies the
! database with the same name as the connecting user. Otherwise,
! this is the name of a specific PostgreSQL
! database.
--- 134,165 ----
database
! Specifies the database for this record. The value
all specifies that it applies to all
databases, while the value sameuser identifies the
! database with the same name as the connecting user. Otherwise,
! this is the name of a specific
! PostgreSQL database. Multiple database
! names can be supplied by separating them with commas. A file
! containing database names can be specified by preceding the file
! name with @. The file must be in the same directory
! as pg_hba.conf.
!
!
!
!
!
! user
!
!
! Specifies the user for this record. The value
! all specifies that it applies to all users.
! Otherwise, this is the name of a specific
! PostgreSQL user. Multiple user
! names can be supplied by separating them with commas. A file
! containing user names can be specified by preceding the file
! name with @. The file must be in the same directory
! as pg_hba.conf.
***************
*** 149,158 ****
IP mask
! These two fields specify to which client machines a
! host or hostssl
! record applies, based on their IP
! address. (Of course IP addresses can be spoofed but this
consideration is beyond the scope of
PostgreSQL.) The precise logic is that
--- 169,177 ----
IP mask
! These two fields specify the client machine IP addresses
! (host or hostssl) for this
! record. (Of course IP addresses can be spoofed but this
consideration is beyond the scope of
PostgreSQL.) The precise logic is that
***************
*** 169,178 ****
authentication method
! Specifies the method that users must use to authenticate themselves
! when connecting under the control of this authentication record.
! The possible choices are summarized here,
! details are in .
--- 188,196 ----
authentication method
! Specifies the authentication method to use when connecting via
! this record. The possible choices are summarized here; details
! are in .
***************
*** 190,255 ****
reject
! The connection is rejected unconditionally. This is mostly
! useful to filter out certain hosts from a group.
! password
! The client is required to supply a password which is required to
! match the database password that was set up for the user.
!
!
!
! An optional file name may be specified after the
! password keyword. This file is expected to
! contain a list of users who may connect using this record,
! and optionally alternative passwords for them.
!
!
!
! The password is sent over the wire in clear text. For better
! protection, use the md5 or
! crypt methods.
! md5
! Like the password method, but the password
! is sent over the wire encrypted using a simple
! challenge-response protocol. This protects against incidental
! wire-sniffing. This is now the recommended choice for
! password-based authentication.
!
!
!
! The name of a file may follow the
! md5 keyword. It contains a list of users
! who may connect using this record.
! crypt
! Like the md5 method but uses older crypt
! encryption, which is needed for pre-7.2
! clients. md5 is
! preferred for 7.2 and later clients. The crypt
! method is not compatible with encrypting passwords in
! pg_shadow, and may fail if client and server
! machines have different implementations of the crypt() library
! routine.
--- 208,248 ----
reject
! The connection is rejected unconditionally. This is useful for
! filtering out certain hosts from a group.
! md5
! Requires the client to supply an MD5 encrypted password for
! authentication. This is the only method that allows encrypted
! passwords to be stored in pg_shadow.
! crypt
! Like md5 method but uses older crypt
! encryption, which is needed for pre-7.2 clients.
! md5 is preferred for 7.2 and later clients.
! password
! Same as "md5", but the password is sent in cleartext over the
! network. This should not be used on untrusted networks.
!
***************
*** 278,311 ****
ident
! The identity of the user as determined on login to the
! operating system is used by PostgreSQL
! to determine whether the user
! is allowed to connect as the requested database user.
! For TCP/IP connections the user's identity is determined by
! contacting the ident server on the client
! host. (Note that this is only as reliable as the remote ident
! server; ident authentication should never be used for remote hosts
! whose administrators are not trustworthy.)
! On operating systems
! supporting SO_PEERCRED requests for Unix domain sockets,
! ident authentication is possible for local connections;
! the system is then asked for the connecting user's identity.
! On systems without SO_PEERCRED requests, ident authentication
! is only available for TCP/IP connections. As a workaround,
! it is possible to
! specify the localhost address
! 127.0.0.1 and make connections
! to this address.
!
!
! The authentication option following
! the ident keyword specifies the name of an
! ident map that specifies which operating
! system users equate with which database users. See below for
! details.
--- 271,306 ----
ident
! For TCP/IP connections, authentication is done by contacting
! the ident server on the client host.
! This is only as secure as the client machine. You must specify
! the map name after the 'ident' keyword. It determines how to
! map remote user names to PostgreSQL user names. If you use
! "sameuser", the user names are assumed to be identical. If
! not, the map name is looked up in the $PGDATA/pg_ident.conf
! file. The connection is accepted if that file contains an
! entry for this map name with the ident-supplied username and
! the requested PostgreSQL username.
!
!
! On machines that support unix-domain socket credentials
! (currently Linux, FreeBSD, NetBSD, and BSD/OS), ident allows
! reliable authentication of 'local' connections without ident
! running on the local machine.
!
!
! On systems without SO_PEERCRED requests, ident
! authentication is only available for TCP/IP connections. As a
! work around, it is possible to specify the localhost address 127.0.0.1 and make connections to this
! address.
! Following the ident keyword, an ident
! map name should be supplied which specifies which
! operating system users equate with which database users. See
! below for details.
***************
*** 315,331 ****
This authentication type operates similarly to
! password, with the main difference that
! it will use PAM (Pluggable Authentication Modules) as the
! authentication mechanism. The authentication
! option following the pam keyword
! specifies the service name that will be passed to PAM. The
! default service name is postgresql.
! For more information about PAM, please read the Linux-PAM
! Page and/or the Solaris PAM
! Page.
--- 310,325 ----
This authentication type operates similarly to
! password except that it uses PAM
! (Pluggable Authentication Modules) as the authentication
! mechanism. The default PAM service name is
! postgresql. You can optionally supply you
! own service name after the pam keyword in the
! file. For more information about PAM, please read the L
! inux-PAM Page and the Solaris PAM Page.
***************
*** 336,377 ****
-
- authentication option
-
-
- This field is interpreted differently depending on the
- authentication method, as described above.
-
-
-
Since the pg_hba.conf records are examined
sequentially for each connection attempt, the order of the records is
! very significant. Typically, earlier records will have tight
! connection match parameters and weaker authentication methods,
! while later records will have looser match parameters and stronger
! authentication methods. For example, one might wish to use
! trust authentication for local TCP connections but
! require a password for remote TCP connections. In this case a
! record specifying trust authentication for connections
! from 127.0.0.1 would appear before a record specifying password
! authentication for a wider range of allowed client IP addresses.
SIGHUP
! The pg_hba.conf file is read on startup
! and when the postmaster receives a
SIGHUP signal. If you edit the file on an
active system, you will need to signal the postmaster
! (using pg_ctl reload or kill -HUP)
! to make it re-read the file.
--- 330,362 ----
Since the pg_hba.conf records are examined
sequentially for each connection attempt, the order of the records is
! significant. Typically, earlier records will have tight connection
! match parameters and weaker authentication methods, while later
! records will have looser match parameters and stronger authentication
! methods. For example, one might wish to use trust
! authentication for local TCP connections but require a password for
! remote TCP connections. In this case a record specifying
! trust authentication for connections from 127.0.0.1 would
! appear before a record specifying password authentication for a wider
! range of allowed client IP addresses.
SIGHUP
! The pg_hba.conf file is read on startup and when
! the postmaster receives a
SIGHUP signal. If you edit the file on an
active system, you will need to signal the postmaster
! (using pg_ctl reload or kill -HUP) to make it
! re-read the file.
***************
*** 382,408 ****
An example <filename>pg_hba.conf</filename> file
! # 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
# The same, over Unix-socket connections:
! local all trust
# 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
# host identifies him as (typically his Unix username):
! 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"
! # if the user's password in pg_shadow is correctly supplied:
! host template1 192.168.12.10 255.255.255.255 md5
# 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
--- 367,393 ----
An example <filename>pg_hba.conf</filename> file
! # TYPE DATABASE USER IP_ADDRESS MASK AUTHTYPE
# Allow any user on the local system to connect to any
# database under any username, but only via an IP connection:
! host all all 127.0.0.1 255.255.255.255 trust
# The same, over Unix-socket connections:
! local all all trust
# 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
# host identifies him as (typically his Unix username):
! host template1 all 192.168.93.0 255.255.255.0 ident sameuser
# Allow a user from host 192.168.12.10 to connect to database "template1"
! # if the user's password is correctly supplied:
! host template1 all 192.168.12.10 255.255.255.255 md5
# 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
***************
*** 410,417 ****
# else on the Internet. The zero mask means that no bits of the host IP
# address are considered, so it matches any host:
! host all 192.168.54.1 255.255.255.255 reject
! 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
# pass the ident check. If, for example, ident says the user is "bryanh"
--- 395,402 ----
# else on the Internet. The zero mask means that no bits of the host IP
# address are considered, so it matches any host:
! host all all 192.168.54.1 255.255.255.255 reject
! host all 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
# pass the ident check. If, for example, ident says the user is "bryanh"
***************
*** 419,425 ****
# is allowed if there is an entry in pg_ident.conf for map "omicron" that
# says "bryanh" is allowed to connect as "guest1":
! host all 192.168.0.0 255.255.0.0 ident omicron
# If these are the only two lines for local connections, they will allow
# local users to connect only to their own databases (database named the
--- 404,410 ----
# is allowed if there is an entry in pg_ident.conf for map "omicron" that
# says "bryanh" is allowed to connect as "guest1":
! host all all 192.168.0.0 255.255.0.0 ident omicron
# If these are the only two lines for local connections, they will allow
# local users to connect only to their own databases (database named the
***************
*** 429,436 ****
# cases. (If you prefer to use ident authorization, an ident map can
# serve a parallel purpose to the password list file used here.)
! local sameuser md5
! local all md5 admins
--- 414,421 ----
# cases. (If you prefer to use ident authorization, an ident map can
# serve a parallel purpose to the password list file used here.)
! local sameuser all md5
! local all @admins md5
***************
*** 490,575 ****
Password authentication
! password
! MD5
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
! database user is stored in the pg_shadow system catalog table.
! Passwords can be managed with the query language commands
! CREATE USER and ALTER USER,
! e.g., CREATE USER foo WITH PASSWORD
! 'secret';. By default, that is, if no password has
! been set up, the stored password is NULL
! and password authentication will always fail for that user.
To restrict the set of users that are allowed to connect to certain
! databases, list the set of users in a separate file (one user name
! per line) in the same directory that pg_hba.conf is in,
! and mention the (base) name of the file after the
! password, md5, or crypt keyword,
! respectively, in pg_hba.conf. If you do not use this
! feature, then any user that is known to the database system can
! connect to any database (so long as he supplies the correct password,
! of course).
!
!
!
! These files can also be used to apply a different set of passwords
! to a particular database or set thereof. In that case, the files
! have a format similar to the standard Unix password file
! /etc/passwd, that is,
!
! username:password
!
! Any extra colon-separated fields following the password are
! ignored. The password is expected to be encrypted using the
! system's crypt() function. The utility
! program pg_passwd that is installed
! with PostgreSQL can be used to manage
! these password files.
!
!
!
! Lines with and without passwords can be mixed in secondary
! password files. Lines without password indicate use of the main
! password in pg_shadow that is managed by
! CREATE USER and ALTER USER. Lines with
! passwords will cause that password to be used. A password entry of
! + also means using the pg_shadow password.
!
!
!
! Alternative passwords cannot be used when using the md5
! or crypt methods. The file will be read as
! usual, but the password field will simply be ignored and the
! pg_shadow password will always be used.
!
!
!
! Note that using alternative passwords like this means that one can
! no longer use ALTER USER to change one's
! password. It will appear to work but the password one is
! changing is not the password that the system will end up
! using.
--- 475,522 ----
Password authentication
! MD5
! crypt
!
!
! password
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 pre-7.2
! 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 database user is stored in the pg_shadow system
! catalog table. Passwords can be managed with the query language
! commands CREATE USER and ALTER
! USER, e.g., CREATE USER foo WITH PASSWORD
! 'secret';. By default, that is, if no password has been
! set up, the stored password is NULL and password
! authentication will always fail for that user.
To restrict the set of users that are allowed to connect to certain
! databases, list the users separated by commas, or in a separate
! file. The file should contain user names separated by commas or one
! user name per line, and be in the same directory as
! pg_hba.conf. Mention the (base) name of the file
! preceded by @in the USER column. The
! DATABASE column can similarly accept a list of values or
! a file name.
***************
*** 588,597 ****
Kerberos system is far beyond the scope
of this document; in all generality it can be quite complex (yet
powerful). The Kerberos
! FAQ or MIT Project Athena can be
! a good starting point for exploration. Several sources for
Kerberos distributions exist.
--- 535,544 ----
Kerberos system is far beyond the scope
of this document; in all generality it can be quite complex (yet
powerful). The Kerb
! eros FAQ or MIT Project Athena can be a
! good starting point for exploration. Several sources for
Kerberos distributions exist.
***************
*** 606,639 ****
PostgreSQL operates like a normal Kerberos service.
The name of the service principal is
! servicename/hostname@realm, where
! servicename is postgres
! (unless a different service name was selected at configure time
! with ./configure --with-krb-srvnam=whatever).
! hostname is the fully qualified domain name of the server
! machine. The service principal's realm is the preferred realm of the
! server machine.
! Client principals must have their PostgreSQL user name as
! their first component, for example
! pgusername/otherstuff@realm.
! At present the realm of the client is not checked by
! PostgreSQL; so
! if you have cross-realm authentication enabled, then any principal
! in any realm that can communicate with yours will be accepted.
! Make sure that your server key file is readable (and
! preferably only readable) by the
! PostgreSQL server account (see
! ). The location of the key file
! is specified with the krb_server_keyfile run time
! configuration parameter. (See also .)
! The default is /etc/srvtab if you are using Kerberos 4
! and FILE:/usr/local/pgsql/etc/krb5.keytab (or whichever
directory was specified as sysconfdir at build time)
with Kerberos 5.
--- 553,585 ----
PostgreSQL operates like a normal Kerberos service.
The name of the service principal is
! servicename/hostname@realm, where
! servicename is postgres (unless a
! different service name was selected at configure time with
! ./configure --with-krb-srvnam=whatever).
! hostname is the fully qualified domain name of the
! server machine. The service principal's realm is the preferred realm
! of the server machine.
! Client principals must have their PostgreSQL user
! name as their first component, for example
! pgusername/otherstuff@realm. At present the realm of
! the client is not checked by PostgreSQL; so if you
! have cross-realm authentication enabled, then any principal in any
! realm that can communicate with yours will be accepted.
! Make sure that your server key file is readable (and preferably only
! readable) by the PostgreSQL server
! account (see ). The location of the
! key file is specified with the krb_server_keyfile run
! time configuration parameter. (See also .) The default is /etc/srvtab
! if you are using Kerberos 4 and
! FILE:/usr/local/pgsql/etc/krb5.keytab (or whichever
directory was specified as sysconfdir at build time)
with Kerberos 5.
***************
*** 649,666 ****
When connecting to the database make sure you have a ticket for a
! principal matching the requested database user name.
! An example: For database user name fred, both principal
fred@EXAMPLE.COM and
! fred/users.example.com@EXAMPLE.COM can be
! used to authenticate to the database server.
! If you use mod_auth_krb and mod_perl on your Apache web server,
! you can use AuthType KerberosV5SaveCredentials with a mod_perl
! script. This gives secure database access over the web, no extra
! passwords required.
--- 595,614 ----
When connecting to the database make sure you have a ticket for a
! principal matching the requested database user name. An example: For
! database user name fred, both principal
fred@EXAMPLE.COM and
! fred/users.example.com@EXAMPLE.COM can be used to
! authenticate to the database server.
! If you use mod_auth_krb and
! mod_perl on your
! Apache web server, you can use
! AuthType KerberosV5SaveCredentials with a
! mod_perl script. This gives secure
! database access over the web, no extra passwords required.
***************
*** 707,761 ****
! 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 local connections on such a system.
When using ident-based authentication, after having determined the
name of the operating system user that initiated the connection,
! PostgreSQL checks whether that user is allowed
! to connect as the database user he is requesting to connect as.
! This is controlled by the ident map
! argument that follows the ident keyword in the
! pg_hba.conf file. There is a predefined ident map
! sameuser, which allows any operating system
! user to connect as the database user of the same name (if the
! latter exists). Other maps must be created manually.
! pg_ident.conf
! Ident maps other than sameuser are defined
! in the file pg_ident.conf
! in the data directory, which contains lines of the general form:
map-name ident-username database-username
! Comments and whitespace are handled in the usual way.
! The map-name is an arbitrary name that will be
! used to refer to this mapping in pg_hba.conf.
! The other two fields specify which operating system user is
! allowed to connect as which database user. The same
! map-name can be used repeatedly to specify more
! user-mappings within a single map. There is no restriction regarding
! how many
! database users a given operating system user may correspond to and vice
! versa.
SIGHUP
! The pg_ident.conf file is read on startup
! and when the postmaster receives a
SIGHUP signal. If you edit the file on an
active system, you will need to signal the postmaster
! (using pg_ctl reload or kill -HUP)
! to make it re-read the file.
--- 655,708 ----
! 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 local
! connections on such systems.
When using ident-based authentication, after having determined the
name of the operating system user that initiated the connection,
! PostgreSQL checks whether that user is
! allowed to connect as the database user he is requesting to connect
! as. This is controlled by the ident map argument that follows the
! ident keyword in the pg_hba.conf
! file. There is a predefined ident map sameuser,
! which allows any operating system user to connect as the database
! user of the same name (if the latter exists). Other maps must be
! created manually.
! pg_ident.conf Ident maps
! other than sameuser are defined in the file
! pg_ident.conf in the data directory, which
! contains lines of the general form:
map-name ident-username database-username
! Comments and whitespace are handled in the usual way. The
! map-name is an arbitrary name that will be used to
! refer to this mapping in pg_hba.conf. The other
! two fields specify which operating system user is allowed to connect
! as which database user. The same map-name can be
! used repeatedly to specify more user-mappings within a single map.
! There is no restriction regarding how many database users a given
! operating system user may correspond to and vice versa.
SIGHUP
! The pg_ident.conf file is read on startup and
! when the postmaster receives a
SIGHUP signal. If you edit the file on an
active system, you will need to signal the postmaster
! (using pg_ctl reload or kill -HUP) to make it
! re-read the file.
***************
*** 763,775 ****
conjunction with the pg_hba.conf file in is shown in . In this example setup, anyone
! logged in to a machine on the 192.168 network that does not have
! the Unix user name bryanh, ann, or robert would not be granted access.
! Unix user robert would only be allowed access when he tries to
! connect as PostgreSQL user bob,
! not as robert
! or anyone else. ann would only be allowed to connect as
! ann. User bryanh would be allowed to connect as either
bryanh himself or as guest1.
--- 710,723 ----
conjunction with the pg_hba.conf file in