Обсуждение: 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
Dallas N Antley <dna+pgsql@clas.ufl.edu> writes:
> 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
/- On Monday (8/16/2004 19:35) Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dallas N Antley <dna+pgsql@clas.ufl.edu> writes: > > 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. > 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
Dallas N Antley wrote: > /- On Monday (8/16/2004 19:35) Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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 -- Get your mouse off of there! You don't know where that email has been!