7.4.3 and PAM authentication failures

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