Fix pg_pwd caching mechanism, which was broken by changes to fork

postmaster children before client auth step.  Postmaster now rereads
pg_pwd on receipt of SIGHUP, the same way that pg_hba.conf is handled.
No cycles need be expended to validate password cache validity during
connection startup.

Author: tglsfdc

doc/src/sgml/client-auth.sgml

@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.22 2001/10/04 22:27:18 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.23 2001/11/02 18:39:57 tgl Exp $ -->
 
 <chapter id="client-authentication">
  <title>Client Authentication</title>
@@ -67,6 +67,19 @@
    tabs.  Records cannot be continued across lines.
   </para>
 
+  <para>
+   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 <quote>fall-through</> or
+   <quote>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.
+  </para>
+
   <para>
    A record may have one of the three formats
    <synopsis>
@@ -107,7 +120,9 @@ hostssl <replaceable>database</replaceable> <replaceable>IP-address</replaceable
        TCP/IP. To make use of this option the server must be
        built with SSL support enabled. Furthermore, SSL must be
        enabled with the <option>-l</> option or equivalent configuration
-       setting when the server is started.
+       setting when the server is started.  (Note: <literal>host</literal>
+       records will match either SSL or non-SSL connection attempts, but
+       <literal>hostssl</literal> records match only SSL connections.)
       </para>
      </listitem>
     </varlistentry>
@@ -131,8 +146,9 @@ hostssl <replaceable>database</replaceable> <replaceable>IP-address</replaceable
      <term><replaceable>IP mask</replaceable></term>
      <listitem>
       <para>
-       These two fields control to which hosts a
-       <literal>host</literal> record applies, based on their IP
+       These two fields specify to which client machines a
+       <literal>host</literal> or <literal>hostssl</literal>
+       record applies, based on their IP
        address. (Of course IP addresses can be spoofed but this
        consideration is beyond the scope of
        <productname>Postgres</productname>.) The precise logic is that
@@ -151,7 +167,8 @@ hostssl <replaceable>database</replaceable> <replaceable>IP-address</replaceable
      <listitem>
       <para>
        Specifies the method that users must use to authenticate themselves
-       when connecting to that database. The possible choices follow,
+       when connecting under the control of this authentication record.
+       The possible choices are summarized here,
        details are in <xref linkend="auth-methods">.
 
        <variablelist>
@@ -322,17 +339,27 @@ hostssl <replaceable>database</replaceable> <replaceable>IP-address</replaceable
      </listitem>
     </varlistentry>
    </variablelist>
+  </para>
 
-   The first record that matches the client IP address and requested
-   database name of a connection attempt is used to do the
-   authentication step.  There is no <quote>fall-through</> or
-   <quote>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.
+  <para>
+   Since the <filename>pg_hba.conf</filename> records are examined
+   sequentially for each connection attempt, 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
+   <literal>trust</> authentication for local TCP connections but
+   require a password for remote TCP connections.  In this case a
+   record specifying <literal>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.
   </para>
 
   <para>
-   The <filename>pg_hba.conf</filename> file is loaded only on startup
+    <indexterm>
+     <primary>SIGHUP</primary>
+    </indexterm>
+   The <filename>pg_hba.conf</filename> file is read on startup
    and when the <application>postmaster</> receives a
    <systemitem>SIGHUP</systemitem> signal. If you edit the file on an
    active system, you will need to signal the <application>postmaster</>
@@ -632,15 +659,16 @@ host         all        192.168.0.0    255.255.0.0        ident     omicron
     to connect as the database user he is requesting to connect as.
     This is controlled by the ident map
     argument that follows the <literal>ident</> keyword in the
-    <filename>pg_hba.conf</filename> file. The simplest ident map is
+    <filename>pg_hba.conf</filename> file. There is a predefined ident map
     <literal>sameuser</literal>, 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.
    </para>
 
    <para>
     <indexterm><primary>pg_ident.conf</primary></indexterm>
-    Ident maps are held in the file <filename>pg_ident.conf</filename>
+    Ident maps other than <literal>sameuser</literal> are defined
+    in the file <filename>pg_ident.conf</filename>
     in the data directory, which contains lines of the general form:
 <synopsis>
 <replaceable>map-name</> <replaceable>ident-username</> <replaceable>database-username</>
@@ -657,6 +685,18 @@ host         all        192.168.0.0    255.255.0.0        ident     omicron
     versa.
    </para>
 
+  <para>
+    <indexterm>
+     <primary>SIGHUP</primary>
+    </indexterm>
+   The <filename>pg_ident.conf</filename> file is read on startup
+   and when the <application>postmaster</> receives a
+   <systemitem>SIGHUP</systemitem> signal. If you edit the file on an
+   active system, you will need to signal the <application>postmaster</>
+   (using <application>pg_ctl reload</> or <application>kill -HUP</>)
+   to make it re-read the file.
+  </para>
+
    <para>
     A <filename>pg_ident.conf</filename> file that could be used in
     conjunction with the <filename>pg_hba.conf</> file in <xref

doc/src/sgml/runtime.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.91 2001/10/31 20:35:02 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.92 2001/11/02 18:39:57 tgl Exp $
 -->
 
 <Chapter Id="runtime">
@@ -479,8 +479,10 @@ syslog = 2
      <primary>SIGHUP</primary>
     </indexterm>
     The configuration file is reread whenever the postmaster receives
-    a <systemitem>SIGHUP</> signal. This signal is also propagated to all running
-    backend processes, so that running sessions get the new default.
+    a <systemitem>SIGHUP</> signal (which is most easily sent by means
+    of <application>pg_ctl reload</>).  The postmaster also propagates
+    this signal to all already-running backend processes, so that
+    existing sessions also get the new default.
     Alternatively, you can send the signal to only one backend process
     directly.
    </para>

src/backend/commands/user.c

@@ -6,7 +6,7 @@
  * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $Header: /cvsroot/pgsql/src/backend/commands/user.c,v 1.87 2001/11/01 18:09:58 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/commands/user.c,v 1.88 2001/11/02 18:39:57 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -15,6 +15,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
+#include <signal.h>
 #include <unistd.h>
 
 #include "access/heapam.h"
@@ -33,14 +34,15 @@
 #include "utils/syscache.h"
 
 
-static void CheckPgUserAclNotNull(void);
 extern bool Password_encryption;
 
+static void CheckPgUserAclNotNull(void);
+
 /*---------------------------------------------------------------------
  * write_password_file / update_pg_pwd
  *
  * copy the modified contents of pg_shadow to a file used by the postmaster
- * for user authentication.  The file is stored as $PGDATA/pg_pwd.
+ * for user authentication.  The file is stored as $PGDATA/global/pg_pwd.
  *
  * This function set is both a trigger function for direct updates to pg_shadow
  * as well as being called directly from create/alter/drop user.
@@ -57,7 +59,6 @@ write_password_file(Relation rel)
 			   *tempname;
 	int			bufsize;
 	FILE	   *fp;
-	int			flagfd;
 	mode_t		oumask;
 	HeapScanDesc scan;
 	HeapTuple	tuple;
@@ -133,7 +134,7 @@ write_password_file(Relation rel)
 		/*
 		 * The extra columns we emit here are not really necessary. To remove
 		 * them, the parser in backend/libpq/crypt.c would need to be
-		 * adjusted.  Initdb might also need adjustments.
+		 * adjusted.
 		 */
 		fprintf(fp,
 				"%s"
@@ -168,6 +169,7 @@ write_password_file(Relation rel)
 
 	/*
 	 * Rename the temp file to its final name, deleting the old pg_pwd.
+	 * We expect that rename(2) is an atomic action.
 	 */
 	if (rename(tempname, filename))
 		elog(ERROR, "rename %s to %s: %m", tempname, filename);
@@ -176,19 +178,10 @@ write_password_file(Relation rel)
 	pfree((void *) filename);
 
 	/*
-	 * Create a flag file the postmaster will detect the next time it
-	 * tries to authenticate a user.  The postmaster will know to reload
-	 * the pg_pwd file contents.  Note: we used to elog(ERROR) if the file
-	 * creation failed, but it's a little silly to abort the transaction
-	 * at this point, so let's just make it a NOTICE.
+	 * Signal the postmaster to reload its password-file cache.
 	 */
-	filename = crypt_getpwdreloadfilename();
-	flagfd = BasicOpenFile(filename, O_WRONLY | O_CREAT, 0600);
-	if (flagfd < 0)
-		elog(NOTICE, "write_password_file: unable to write %s: %m", filename);
-	else
-		close(flagfd);
-	pfree((void *) filename);
+	if (IsUnderPostmaster)
+		kill(getppid(), SIGHUP);
 }