7.4.3 and PAM authentication failures - Mailing list pgsql-admin

Folks,

I apologise if this is the wrong list for my query.  I've looked
through the FAQ, list archives, and Google for an answer, with no
solution listed, although the same question has been asked many times
before.

I think I know why pam authentication fails with the pam_unix*
modules, but would appreciate your opinion.

First, some details:

       Version:  PostgreSQL 7.4.3
       OS:     Solaris 8 10/01 w/ July 8_Recommended patch cluster
       Compiler: Sun WorkShop 6 update 2 C 5.3 2001/05/15

I've built the programs using '--with-pam'.  'make check' completes
successfully.

| % cat pg_hba.conf
| # TYPE  DATABASE    USER        IP-ADDRESS        IP-MASK           METHOD
| local   all         all                                             trust
| host    all         all         127.0.0.1         255.255.255.255   pam
| % egrep '^postgresql' /etc/pam.conf
| postgresql     auth required           pam_unix_auth.so.1
| postgresql     account required        pam_unix_account.so.1

Unfortunately, authentication fails.

| % psql -h localhost template1
| Password:
| psql: FATAL:  PAM authentication failed for user "dna"

The logs note:

| LOG:  00000: pam_authenticate failed: Authentication failed
| LOCATION:  CheckPAMAuth, auth.c:712
| FATAL:  28000: PAM authentication failed for user "dna"
| LOCATION:  auth_failed, auth.c:395

Of course, everything works via a socket connection, since that's just
using "trust".

| % psql template1
| Welcome to psql 7.4.3, the PostgreSQL interactive terminal.
[ ... ]
| template1=> \list
|
|         List of databases
|    Name    |  Owner   | Encoding
| -----------+----------+-----------
|  template0 | postgres | SQL_ASCII
|  template1 | postgres | SQL_ASCII
|  testdb    | dna      | SQL_ASCII
| (3 rows)

I've tested every pam_unix*.so combination I can think of.  They all
failed.  I then truss'ed the running postmaster process, and noted:

[ ... ]
| 25789:  recv(10, " p\0\0\0\f P A S S W O R D".., 8192, 0)       = 13
| 25789:  door_info(3, 0xFFBEE0F8)                        = 0
| 25789:  door_call(3, 0xFFBEE0E0)                        = 0
| 25789:  open("/etc/shadow", O_RDONLY)                   Err#13 EACCES
| 25789:  open("/etc/shadow", O_RDONLY)                   Err#13 EACCES
| 25789:  getpid()                                        = 25789 [25779]

Error #13 is "permission denied".  This makes sense now, since
/etc/shadow, passwd-adjunct, C2-NIS, or any similar password
authentication system requires an effective uid of 0, the superuser.
Since postmaster runs as user "postgres", there's no method for
postmaster to read the system password, and so PAM authentication will
not work for Unix-style system authentication.

Does this sound like a reasonable explanation for the pam_unix
failures we've seen reported?  Can anyone see a solution that doesn't
require switching to a different authentication method?

               Dallas