# # 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 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 local # (127.0.0.1) or remote host. AUTH_ARGUMENT is required and # maps names found in the $PGDATA/pg_ident.conf file. The # connection is accepted if the file contains an entry for # this map name with the ident-supplied username and the # requested PostgreSQL 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. # # krb5: Kerberos V5 authentication is used. # # 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-domain socket connections support only the AUTH_TYPEs of # "trust", "password", "crypt", and "reject". # # # # 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 crypt # # 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