Skip site navigation (1) Skip section navigation (2)

7.4.3 and PAM authentication failures

From: Dallas N Antley <dna+pgsql(at)clas(dot)ufl(dot)edu>
To: pgsql-admin(at)postgresql(dot)org
Subject: 7.4.3 and PAM authentication failures
Date: 2004-08-16 20:49:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin

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

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

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

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?



pgsql-admin by date

Next:From: Christopher BrowneDate: 2004-08-16 22:52:42
Subject: Re: [ADMIN] Pseudo-Off-topic-survey: Opinions about future of Postgresql(MySQL)?
Previous:From: Shahbaz JaveedDate: 2004-08-16 20:28:48
Subject: Re: [ADMIN] Pseudo-Off-topic-survey: Opinions about future of Postgresql(MySQL)?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group