From 43a3543a4eb412a895df911eba9d8671ded45c54 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 4 Apr 2002 04:25:54 +0000 Subject: Authentication improvements: A new pg_hba.conf column, USER Allow specifiction of lists of users separated by commas Allow group names specified by + Allow include files containing lists of users specified by @ Allow lists of databases, and database files Allow samegroup in database column to match group name matching dbname Removal of secondary password files Remove pg_passwd utility Lots of code cleanup in user.c and hba.c New data/global/pg_pwd format New data/global/pg_group file --- doc/src/sgml/client-auth.sgml | 593 ++++++++++++++++++---------------------- doc/src/sgml/ref/allfiles.sgml | 3 +- doc/src/sgml/ref/pg_passwd.sgml | 123 --------- doc/src/sgml/reference.sgml | 3 +- 4 files changed, 274 insertions(+), 448 deletions(-) delete mode 100644 doc/src/sgml/ref/pg_passwd.sgml (limited to 'doc/src') diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml index 76542f98720..4afd179a4b1 100644 --- a/doc/src/sgml/client-auth.sgml +++ b/doc/src/sgml/client-auth.sgml @@ -1,5 +1,5 @@ @@ -10,14 +10,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.33 2002/03/22 19:20:06 - 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. + 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. Therefore, it is + essential to restrict which database users can connect. @@ -30,20 +29,19 @@ $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.33 2002/03/22 19:20:06 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. + client authentication methods. The method to be used can be selected + on the basis of (client) host, database, and user. - PostgreSQL database user names are logically + 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 + 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. + 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,39 +54,39 @@ $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.33 2002/03/22 19:20:06 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. + /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. + 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 or names, + (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 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 + these parameters. The first record with a matching connection type, + client address, requested database, and user name is used to perform + authentication. 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. + fails, subsequent records are not considered. If no record matches, + access is denied. A record may have one of the three formats -local database authentication-method [ authentication-option ] -host database IP-address IP-mask authentication-method [ authentication-option ] -hostssl database IP-address IP-mask authentication-method [ authentication-option ] +local database user authentication-method [ authentication-option ] +host database user IP-address IP-mask authentication-method +hostssl database user IP-address IP-mask authentication-method The meaning of the fields is as follows: @@ -97,7 +95,7 @@ hostssl database IP-addresslocal - This record pertains to connection attempts over Unix domain + This record applies to connection attempts using Unix domain sockets. @@ -107,10 +105,11 @@ hostssl database IP-addresshost - 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. + 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,13 +118,13 @@ hostssl database IP-addresshostssl - This record pertains to connection attempts with SSL over + 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,12 +133,35 @@ hostssl database IP-addressdatabase - Specifies the database that this record applies to. The value + 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. + database with the same name as the connecting user. The value + samegroup identifies a group with the same name as + the database name. Only members of this group can connect to the + database. 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. Group names can + be specified by preceding the group name with +. 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,10 +171,9 @@ hostssl database IP-addressIP 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 + 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,10 +190,9 @@ hostssl database IP-addressauthentication 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 . + Specifies the authentication method to use when connecting via + this record. The possible choices are summarized here; details + are in . @@ -190,66 +210,41 @@ hostssl database IP-addressreject - The connection is rejected unconditionally. This is mostly - useful to filter out certain hosts from a group. + The connection is rejected unconditionally. This is useful for + filtering out certain hosts from a group. - password + md5 - 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. + 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. - md5 + crypt - 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. + 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. - crypt + password - 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. + Same as "md5", but the password is sent in cleartext over the + network. This should not be used on untrusted networks. + @@ -278,34 +273,36 @@ hostssl database IP-addressident - 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. - + 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 user name and + the requested PostgreSQL user name. + + + 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 workaround, - it is possible to - specify the localhost address - 127.0.0.1 and make connections - to this address. + 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. - 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. + 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,17 +312,16 @@ hostssl database IP-address 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. + 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,42 +332,33 @@ hostssl database IP-address - - 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. + 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 start-up - and when the postmaster receives a + The pg_hba.conf file is read on start-up 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. + (using pg_ctl reload or kill -HUP) to make it + re-read the file. @@ -382,27 +369,27 @@ hostssl database IP-address An example <filename>pg_hba.conf</filename> file -# TYPE DATABASE IP_ADDRESS MASK AUTHTYPE MAP +# 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: +# database under any user name, but only via an IP connection: -host all 127.0.0.1 255.255.255.255 trust +host all all 127.0.0.1 255.255.255.255 trust # The same, over Unix-socket connections: -local all trust +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): +# connect to database "template1" as the same user name that ident on that +# host identifies him as (typically his Unix user name): -host template1 192.168.93.0 255.255.255.0 ident sameuser +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 in pg_shadow is correctly supplied: +# if the user's password is correctly supplied: -host template1 192.168.12.10 255.255.255.255 md5 +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,8 +397,8 @@ host template1 192.168.12.10 255.255.255.255 md5 # 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 +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,7 +406,7 @@ host all 0.0.0.0 0.0.0.0 krb5 # 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 +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,8 +416,8 @@ host all 192.168.0.0 255.255.0.0 ident omicron # 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 +local sameuser all md5 +local all @admins md5 @@ -490,86 +477,49 @@ local all md5 admins Password authentication - password + MD5 - MD5 + crypt + + + password Password-based authentication methods include md5, - crypt, and password. These methods operate + 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). + 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. + 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. + 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 with @in the USER column. The + DATABASE column can similarly accept a list of values or + a file name. You can also specify group names by preceding the group + name with +. @@ -588,10 +538,10 @@ local all md5 admins 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 + url="http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html">Kerb + eros FAQ or MIT Project Athena can be a + good starting point for exploration. Several sources for Kerberos distributions exist. @@ -606,34 +556,33 @@ local all md5 admins 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. + 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. + 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 + 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,18 +598,20 @@ local all md5 admins 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 + 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. + 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. + 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,55 +658,54 @@ local all md5 admins - 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. + 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. + 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: + 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. + 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 start-up - and when the postmaster receives a + The pg_ident.conf file is read on start-up 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. + (using pg_ctl reload or kill -HUP) to make it + re-read the file. @@ -763,13 +713,14 @@ local all md5 admins 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 + 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. @@ -780,7 +731,7 @@ local all md5 admins omicron bryanh bryanh omicron ann ann -# bob has username robert on these machines +# bob has user name robert on these machines omicron robert bob # bryanh can also connect as guest1 omicron bryanh guest1 @@ -799,30 +750,30 @@ omicron bryanh guest1 -No pg_hba.conf entry for host 123.123.123.123, user joeblow, database testdb +No pg_hba.conf entry for host 123.123.123.123, user andym, database testdb - This is what you are most likely to get if you succeed in - contacting the server, but it does not want to talk to you. As the - message suggests, the server refused the connection request - because it found no authorizing entry in its pg_hba.conf + This is what you are most likely to get if you succeed in contacting + the server, but it does not want to talk to you. As the message + suggests, the server refused the connection request because it found + no authorizing entry in its pg_hba.conf configuration file. -Password authentication failed for user 'joeblow' +Password authentication failed for user 'andym' - Messages like this indicate that you contacted the server, and - it is willing to talk to you, but not until you pass the - authorization method specified in the - pg_hba.conf file. Check the password you are - providing, or check your Kerberos or ident software if the - complaint mentions one of those authentication types. + Messages like this indicate that you contacted the server, and it is + willing to talk to you, but not until you pass the authorization + method specified in the pg_hba.conf file. Check + the password you are providing, or check your Kerberos or ident + software if the complaint mentions one of those authentication + types. -FATAL 1: user "joeblow" does not exist +FATAL 1: user "andym" does not exist The indicated user name was not found. @@ -837,9 +788,9 @@ FATAL 1: Database "testdb" does not exist in the system catalog. - Note that the server log may contain more information - about an authentication failure than is reported to the client. - If you are confused about the reason for a failure, check the log. + Note that the server log may contain more information about an + authentication failure than is reported to the client. If you are + confused about the reason for a failure, check the log. diff --git a/doc/src/sgml/ref/allfiles.sgml b/doc/src/sgml/ref/allfiles.sgml index 460f150bc89..61d979a5643 100644 --- a/doc/src/sgml/ref/allfiles.sgml +++ b/doc/src/sgml/ref/allfiles.sgml @@ -1,5 +1,5 @@ @@ -125,7 +125,6 @@ Complete list of usable sgml source files in this directory. - diff --git a/doc/src/sgml/ref/pg_passwd.sgml b/doc/src/sgml/ref/pg_passwd.sgml deleted file mode 100644 index 13125b08e27..00000000000 --- a/doc/src/sgml/ref/pg_passwd.sgml +++ /dev/null @@ -1,123 +0,0 @@ - - - - - 2000-11-18 - - - - pg_passwd - 1 - Application - - - - pg_passwd - change a secondary PostgreSQL password file - - - - - pg_passwd - filename - - - - - Description - - pg_passwd is a tool for manipulating flat - text password files. These files can control client authentication of - the PostgreSQL server. More information - about setting up this authentication mechanism can be found in the - Administrator's Guide. - - - - 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 - name, the second field is the encrypted password. Other fields are - ignored (to allow password files to be shared between applications - that use similar formats). pg_passwd - enables users to interactively add entries to such a file, to alter - passwords of existing entries, and to encrypt such passwords. - - - - Supply the name of the password file as argument to the - pg_passwd command. To be used by - PostgreSQL, the file needs to be located in the server's data - directory, and the base name of the file needs to be specified in the - pg_hba.conf access control file. - - -$ pg_passwd /usr/local/pgsql/data/passwords -File "/usr/local/pgsql/data/passwords" does not exist. Create? (y/n): y -Username: guest -Password: -Re-enter password: - - - where the Password: and Re-enter - password: prompts require the same password input which - is not displayed on the terminal. Note that the password is limited - to eight useful characters by restrictions of the standard crypt(3) - library routine. - - - - The original password file is renamed to - passwords.bk. - - - - To make use of this password file, put a line like the following in - pg_hba.conf: - - -host mydb 133.65.96.250 255.255.255.255 password passwords - - - which would allow access to database mydb from host 133.65.96.250 using - the passwords listed in the passwords file (and - only to the users listed in that file). - - - - - It is also useful to have entries in a password file with empty - password fields. (This is different from an empty password.) Such - entries allow you to restrict users who can access the system. These - entries cannot be managed by pg_passwd, - but you can edit password files manually. - - - - - - See also - - PostgreSQL Administrator's Guide - - - - - diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml index b6b63254462..41d419dd2ea 100644 --- a/doc/src/sgml/reference.sgml +++ b/doc/src/sgml/reference.sgml @@ -1,5 +1,5 @@ @@ -191,7 +191,6 @@ Disable this chapter until we have more functions documented. &initlocation; &ipcclean; &pgCtl; - &pgPasswd; &postgres; &postmaster; -- cgit v1.2.3