7.4.3 and PAM authentication failures

[dna+ (Dallas N Antley)]

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

Post by dna+ (Dallas N Antley)
I think I know why pam authentication fails with the pam_unix*
modules, but would appreciate your opinion.

I think you've proven that the particular PAM modules you are testing
with are useless for programs executing as non-root, but that doesn't
mean the entire concept is broken. Look around ... there are lots of
PAM modules (or at least that's the theory).

BTW, what are those "door_info()" and "door_call()" calls shown in the
truss output? Could it be that those are supposed to get the PAM code
into a higher authorization level?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly

[dna+ (Dallas N Antley)]

Post by Tom Lane

Post by dna+ (Dallas N Antley)
I think I know why pam authentication fails with the pam_unix*
modules, but would appreciate your opinion.

I think you've proven that the particular PAM modules you are testing
with are useless for programs executing as non-root, but that doesn't
mean the entire concept is broken. Look around ... there are lots of
PAM modules (or at least that's the theory).

Correct. I'm only referring to pam_unix* modules. This has come up
on the list a few times, but there's never been a "solution" in any of
the replies.

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

This is why login, dtsession, xscreensaver, etc are setuid under
Solaris, and probably under Linux distributions that use /etc/shadow,
C2-NIS, and/or NIS+. Given the current security model employed by the
postmaster process, this wouldn't be trivial.

Considering the number of times this came up in the archives, and
after getting stuck myself, I'd like to get this added to the FAQ,
assuming I'm correct in my logic.

Post by Tom Lane
BTW, what are those "door_info()" and "door_call()" calls shown in the
truss output? Could it be that those are supposed to get the PAM code
into a higher authorization level?

Doors are a Solaris-specific (AFAIK) type of inter-process
communication -- similar to sockets, but faster. They're used inside
the PAM libraries for name service, syslog calls, etc.

Dallas

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Kris Deugau]

Post by dna+ (Dallas N Antley)

Post by Tom Lane
I think you've proven that the particular PAM modules you are
testing with are useless for programs executing as non-root, but
that doesn't mean the entire concept is broken. Look around ...
there are lots of
PAM modules (or at least that's the theory).

Correct. I'm only referring to pam_unix* modules. This has come up
on the list a few times, but there's never been a "solution" in any
of the replies.

I'm not sure what you're looking for in a solution, but I dug through
the source to one of the pam_unix modules at one point to see why an app
I was writing was misbehaving.

In short, pam_unix specifically reads /etc/passwd and /etc/shadow
(unless your NSS configuration uses NIS, LDAP, or some other
remote-authentication system- and even then it may still need root
access) and if you don't want PAM or your app to be setuid root, you
don't use pam_unix (or any of the other modules that require root access
for one reason or another).

If you want PAM authentication against the system password file, your
app MUST either:

1) Run setuid root

OR

2) Communicate with some external authentication system that runs setuid
root. This can be done relatively easily through PAM; you just have to
find the appropriate modules and authentication daemon. <g>

So far as I understand your original question, you're asking "I want to
authenticate against the system password file, but I don't want my app
[Postgres] to have root priviledges in any way". PAM, in and of itself,
does not inherently require root access to work correctly - UNLESS
you're using a particular PAM module that *does*.... such as pam_unix.

This is by no means unique to Postgres.

-kgd