I have applied the following patch to document PQinitSSL() and
authorBruce Momjian <[email protected]>
Mon, 24 Oct 2005 15:38:37 +0000 (15:38 +0000)
committerBruce Momjian <[email protected]>
Mon, 24 Oct 2005 15:38:37 +0000 (15:38 +0000)
PQregisterThreadLock().

I also remove the crypt() mention in the libpq threading section and
added a single sentence in the client-auth manual page under crypt().
Crypt authentication is so old now that a separate paragraph about it
seemed unwise.

I also added a comment about our use of locking around pqGetpwuid().

doc/src/sgml/client-auth.sgml
doc/src/sgml/libpq.sgml
src/interfaces/libpq/fe-auth.c
src/interfaces/libpq/fe-secure.c

index be986d8ef91bebff9818375b253c73935fbb5499..33c7b4aea387b333faafb29f21143b0a95733411 100644 (file)
@@ -337,6 +337,7 @@ hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>
           authentication.
           Since the password is sent in clear text over the
           network, this should not be used on untrusted networks.
+          It also does not usually work with threaded client applications.
           See <xref linkend="auth-password"> for details.
          </para>
         </listitem>
index 8e6edc808d3c5ee56122f530769e9eda11ebb243..5b583975094b777085f7523a3a550adf7208efae 100644 (file)
@@ -4032,6 +4032,15 @@ however.)
    fail if the server does not present a certificate; therefore, to
    use this feature the server must also have a <filename>root.crt</> file.
   </para>
+
+  <para>
+   If you are using <acronym>SSL</> inside your application (in addition to
+   inside <application>libpq</application>), you can use <function>PQinitSSL(int)</>
+   to tell <application>libpq</application> that the <acronym>SSL</> library
+   has already been initialized by your application.
+  </para>
+
+
 </sect1>
 
 
@@ -4081,12 +4090,12 @@ are not thread-safe and should not be used in multithread programs.
 </para>
 
 <para>
-<application>libpq</application> applications that use the
-<literal>crypt</literal> authentication method rely on the
-<literal>crypt()</literal> operating system function, which is often
-not thread-safe.<indexterm><primary>crypt</><secondary>thread
-safety</></> It is better to use the <literal>md5</literal> method,
-which is thread-safe on all platforms.
+If you are using Kerberos inside your application (in addition to inside 
+<application>libpq</application>), you will need to do locking around 
+Kerberos calls because Kerberos functions are not thread-safe.  See 
+function <function>PQregisterThreadLock</> in the 
+<application>libpq</application> source code for a way to do cooperative 
+locking between <application>libpq</application> and your application.
 </para>
 
 <para>
index 3a0a99bd9b36b88ebb0b44a5303cd937a9bd5ec4..6d11444993e7081251dd4147ed5283fc2c9e194d 100644 (file)
@@ -500,6 +500,16 @@ pg_fe_getauthname(char *PQerrormsg)
        struct passwd *pw = NULL;
 #endif
 
+       /*
+        *      pglock_thread() really only needs to be called around
+        *      pg_krb5_authname(), but some users are using configure
+        *      --enable-thread-safety-force, so we might as well do
+        *      the locking within our library to protect pqGetpwuid().
+        *      In fact, application developers can use getpwuid()
+        *      in their application if they use the locking call we
+        *      provide, or install their own locking function using
+        *      PQregisterThreadLock().
+        */
        pglock_thread();
 
 #ifdef KRB5
index 91a4c7e720a46f34fdb1317a9bf366703e1dcf8e..e2762d647948feff4b372ecdf8f72e323aa87520 100644 (file)
@@ -220,8 +220,8 @@ KWbuHn491xNO25CQWMtem80uKw+pTnisBRF/454n1Jnhub144YRBoN8CAQI=\n\
 
 
 /*
- * Exported (but as yet undocumented) function to allow application to
- * tell us it's already initialized OpenSSL.
+ *     Exported function to allow application to tell us it's already
+ *     initialized OpenSSL.
  */
 void
 PQinitSSL(int do_init)