Обсуждение: pg_hba.conf and Administrator's Guide, 8. Security, User Authentication, Host-Based Access Control

Поиск
Список
Период
Сортировка
Name         :       Oleg Katsitadze
Email address:       geol@cit.sf.ukrtel.net


Short description of the problem
--------------------------------
Misleading description of `crypt' user authentication method in
pg_hba.conf.

Difference between `crypt' and `password' authentication methods is
(probably) not intuitively discernable in Administrator's Guide.


System configuration
--------------------
  Architecture:         Intel Pentium MMX

  Operating System:     Linux 2.4.2-2 (Red Hat Linux release 7.1
Seawolf)

  PostgreSQL version:   PostgreSQL-7.0.3

  Compiler used:        gcc 2.96


Detailed description of the problem
-----------------------------------
Default pg_hba.conf in /usr/local/pgsql/data contains the following
description
of `password' and `crypt' authentication methods:

#   password:   Authentication is done by matching a password supplied
#               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). See pg_passwd(1). If it
#               is omitted then the password is compared with the user's
#               entry in the pg_shadow table.
#
#   crypt:      Same as 'password', but authentication is done by
#               encrypting the password sent over the network.

This may cause confusion for a new user since `crypt' authentication
type is
NOT the same as `password' as it does not look up password file even if
provided
as AUTH_ARGUMENT.  A simple note might be in place for `crypt':

#   crypt:      Same as 'password', but authentication is done by
#               encrypting the password sent over the network.  Note:
unlike
#               'password', 'crypt' does not use password file; password
lookup
#               is always done in pg_shadow table.


Actually, this behavior can be inferred from Administrator's
Guide, 8. Security, User Authentication, Host-Based Access Control,
which reads:

   crypt
          The  client  is asked for a password for the user. This is
sent
          encrypted  (using  crypt(3))  and compared against the
password
          held  in  the  pg_shadow  table.  If  the  passwords match,
the
          connection is allowed.

   password
          The  client  is asked for a password for the user. This is
sent
          in  clear  and  compared  against  the  password  held  in
the
          pg_shadow  table.  If  the  passwords  match, the connection
is
          allowed.  An  optional password file may be specified after
the
          password  keyword  which is used to match the supplied
password
          rather than the pg_shadow table. See pg_passwd.

It may be more convenient for a reader if description of `crypt' method
would stress out that password file is not being looked up.  In any
case, it
will save some hasty readers (like me) several minutes of trying to
configure
`crypt' with a password file, and then coming back to the documentation
to
figure out that `crypt' does not use it.

Thanks,
Oleg


Re: pg_hba.conf and Administrator's Guide, 8. Security, User

От
Bruce Momjian
Дата:
> This may cause confusion for a new user since `crypt' authentication
> type is
> NOT the same as `password' as it does not look up password file even if
> provided
> as AUTH_ARGUMENT.  A simple note might be in place for `crypt':


Attached is the current pg_hba.conf file with some improvements.  Please
let me know what needs changing in this version.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
#
#          PostgreSQL HOST-BASED ACCESS (HBA) CONTROL FILE
#
#
# This file controls:
#     o which hosts are allowed to connect
#     o how users are authenticated on each host
#     o databases accessible by each host
#
# It is read on postmaster startup and when the postmaster receives a SIGHUP.
# If you edit the file on a running system, you have to SIGHUP the postmaster
# for the changes to take effect.
#
# Each line is a new record. Records cannot be continued across multiple
# lines. Comments begin with # and continue to the end of the line.
# Blank lines are ignored. A record consists of tokens separated by
# multiple spaces or tabs.
#
# The first token of a record indicates its type. The remainder of the
# record is interpreted based on its type.
#
# Record Types
# ============
#
# 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:
#
#   host  DBNAME  IP_ADDRESS  ADDRESS_MASK  AUTH_TYPE  [AUTH_ARGUMENT]
#
# DBNAME can be:
#     o the name of a PostgreSQL database
#     o "all" to indicate all databases
#     o "sameuser" to allow access only to databases with the same
#       name as the connecting user
#
# IP_ADDRESS and ADDRESS_MASK are standard dotted decimal IP address and
# mask values. IP addresses can only be specified numerically, not as
# domain or host names.
#
# AUTH_TYPE and AUTH_ARGUMENT are described below.
#
# There can be multiple "host" records, possibly with overlapping sets of
# host addresses. The postmaster finds the first entry that matches the
# connecting host IP address and the requested database name. If no entry
# matches the database/hostname combination, the connection is rejected.
#
#
# hostssl
# -------
#
# The format of this record is identical to "host".
#
# This record identifies a set of network hosts that are permitted to
# connect to databases over secure SSL IP connections. Note that a "host"
# record will also allow SSL connections.  "hostssl" forces these
# hosts to use *only* SSL-secured connections.
#
# This keyword is only available if the server was compiled with SSL
# support enabled.
#
#
# local
# -----
#
# This record identifies the authentication to use when connecting to
# the server via a local UNIX domain socket.  UNIX-socket connections are
# allowed only if this record type appears.
#
# Format:
#   local  DBNAME  AUTH_TYPE  [AUTH_ARGUMENT]
#
# This format is identical to the "host" record type except the IP_ADDRESS
# and ADDRESS_MASK fields are omitted.
#
# As with "host" records, the first "local" record matching the requested
# database name is used.
#
#
#
# Authentication Types (AUTH_TYPE)
# ================================
#
# AUTH_TYPE indicates the method used to authenticate users. The username
# is specified in the connection request.  A different AUTH_TYPE can be
# specified for each record in the file.
#
#   trust:      No authentication is done. Any valid username is accepted,
#         including the PostgreSQL superuser. This option should
#         be used only for hosts where all users are trusted.
#
#   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.
#
#   md5:      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 it. Also, md5 can use usernames stored
#        in secondary password files but not secondary passwords.
#
#   crypt:      Same as "md5", but uses crypt for pre-7.2 clients.  You can
#        not store encrypted passwords if you use this option.
#
#   ident:    For TCP/IP connections, authentication is done by contacting
#        the ident server on the client host.  Remember, this is
#        only as secure as the client machine.  On machines that
#        support unix-domain socket credentials (currently Linux,
#        FreeBSD, NetBSD, and BSD/OS), this method also works for
#        "local" connections.
#
#        AUTH_ARGUMENT is required: it determines how to map
#        remote user names to Postgres user names. The
#        AUTH_ARGUMENT is a map name found 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 Postgres
#        username. The special map name "sameuser" indicates an
#        implied map (not in pg_ident.conf) that maps each ident
#        username to the identical PostgreSQL username.
#
#   krb4:    Kerberos V4 authentication is used.  Allowed only for
#        TCP/IP connections, not for local UNIX-domain sockets.
#
#   krb5:    Kerberos V5 authentication is used.  Allowed only for
#        TCP/IP connections, not for local UNIX-domain sockets.
#
#   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.
#
#   pam:        Authentication is passed off to PAM (PostgreSQL must be
#               configured --with-pam), using the default service name
#               "postgresql" - you can specify your own service name, by
#               setting AUTH_ARGUMENT to the desired service name.
#
#
#
# Examples
# ========
#
#
# 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
#
# 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
# connect to database "template1" as the same username that ident reports
# 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
#
# 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:
#
# TYPE       DATABASE    IP_ADDRESS    MASK               AUTH_TYPE  AUTH_ARGUMENT
# 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 from 192.168.54.1 (since that entry will be matched
# first), but allow Kerberos V5-validated connections from anywhere else
# on the Internet. The zero mask means that no bits of the host IP address
# 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        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. For example, if ident says the user is "james" and
# he requests to connect as PostgreSQL user "guest", the connection is
# allowed if there is an entry in $PGDATA/pg_ident.conf with map name
# "phoenix" that says "james" is allowed to connect as "guest":
#
# 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
# ==================================
#
# This default configuration allows any local user to connect with any
# 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
host       all         127.0.0.1     255.255.255.255    trust