PostgreSQL 7.2 + PAM = authentication failure?

Hello --

I'm trying to get PostgreSQL to use PAM for authentication and hitting a
big, blank brick wall. I'd appreciate any advice anyone can give. (What
I'm trying to accomplish is to allow regular users to connect to the
database server from elsewhere on the network using their existing
system password on the server.)

The database server (192.168.0.1) is running PostgreSQL 7.2.1 on Solaris
7. In pg_hba.conf, the relevant line is:

   hostssl    all         192.168.0.2       255.255.255.255  pam

and /etc/pam.conf contains the following:

   other   auth     required   /usr/lib/security/pam_unix.so.1
   other   account  required   /usr/lib/security/pam_unix.so.1
   other   session  required   /usr/lib/security/pam_unix.so.1
   other   password required   /usr/lib/security/pam_unix.so.1

(I've tried using 'postgresql' instead of 'other' as the service name;
it makes no difference.)

When I try to connect from the client (192.168.0.2), I get the
following:

   $ psql -h 192.168.0.1 -U charlie template1
   Password:
   psql: FATAL 1:  PAM authentication failed for user "charlie"

In the postmaster's logfile on the server, I get:

   2003-02-07 14:49:57 [24198]  DEBUG:  BackendStartup: forked pid=24558
        socket=8
   CheckPAMAuth: pam_authenticate failed: 'Conversation failure'
   2003-02-07 14:49:57 [24558]  FATAL 1:  PAM authentication failed for
        user "charlie"
   2003-02-07 14:49:57 [24558]  DEBUG:  proc_exit(0)
   2003-02-07 14:49:57 [24558]  DEBUG:  shmem_exit(0)
   2003-02-07 14:49:57 [24558]  DEBUG:  exit(0)
   2003-02-07 14:49:57 [24198]  DEBUG:  reaping dead processes
   2003-02-07 14:49:57 [24198]  DEBUG:  child process (pid 24558) exited
        with exit code 0
   2003-02-07 14:50:01 [24198]  DEBUG:  BackendStartup: forked pid=24562
        socket=8
   CheckPAMAuth: pam_authenticate failed: 'Authentication failed'
   2003-02-07 14:50:01 [24562]  FATAL 1:  PAM authentication failed for
        user "charlie"
   2003-02-07 14:50:01 [24562]  DEBUG:  proc_exit(0)
   2003-02-07 14:50:01 [24562]  DEBUG:  shmem_exit(0)
   2003-02-07 14:50:01 [24562]  DEBUG:  exit(0)
   2003-02-07 14:50:01 [24198]  DEBUG:  reaping dead processes
   2003-02-07 14:50:01 [24198]  DEBUG:  child process (pid 24562) exited
        with exit code 0

I see identical behaviour with a Debian 3.0 box (this one running
7.2.3), with one difference: If I change pam_unix.so to pam_permit.so,
it works just fine. So it seems the PAM is working fine, but that
pam_unix.so is not. (There's no pam_permit.so module installed on the
Solaris box, so I can't test this to see if -- as I suspect -- it's true
there, too.)

On the Debian box, I see the following messages in /var/log/auth.log
when using pam_unix.so:

   Feb  7 15:10:42 chornberger-0 su(pam_unix)[29522]: authentication
        failure; logname= uid=1000 euid=0 tty=pts/4 ruser=charlie
        rhost=  user=root
   Feb  7 15:10:44 chornberger-0 su[29522]: pam_authenticate:
        Authentication failure

Alas, I get no such feedback on the Solaris box.

Thanks in avance for any help ...

-Charlie

P.S. I see that this question has been asked before, recently and
repeatedly:

  http://archives.postgresql.org/pgsql-admin/2002-05/msg00075.php
  http://archives.postgresql.org/pgsql-admin/2002-05/msg00233.php
  http://archives.postgresql.org/pgsql-admin/2002-06/msg00110.php
  http://archives.postgresql.org/pgsql-admin/2002-08/msg00281.php
  http://archives.postgresql.org/pgsql-admin/2002-10/msg00066.php

But I have yet to stumble across anything that seemed like a solution.
(One person suggested using pam_ftp.so instead of pam_unix.so ... which
doesn't seem like such a hot prospect to me.)

There was another suggestion at

  http://archives.postgresql.org/pgsql-patches/2002-12/msg00033.php

that PAM authentication failures might have something to do with
MD5-encrypted passwords in pg_shadow, but I can't understand how the
contents of pg_shadow would affect PAM authentication. In any case, I
haven't tried applying the patch that was provided there. Should I?

--
Charles Hornberger <charlie@hss.caltech.edu>