Re: PostgreSQL 7.2 + PAM = authentication failure?

Поиск
Список
Период
Сортировка
От Charles Hornberger
Тема Re: PostgreSQL 7.2 + PAM = authentication failure?
Дата
Msg-id 1045611742.31590.36.camel@chornberger-0
обсуждение исходный текст
Ответ на PostgreSQL 7.2 + PAM = authentication failure?  (Charles Hornberger <charlie@hss.caltech.edu>)
Список pgsql-admin
Hi Stef,

Thanks very much for your response ... but I'm sad to report that I'm
still at a dead-end. I've tried upgrading to 7.3.2 on the Debian box,
but authentication still fails. I've been trying to solve it myself (by
adding a bunch of debugging output into src/backend/libpq/auth.c) but I
don't think I'm making much progress. I still get authentication errors
every time, and I still don't know why. (I haven't tried upgrading the
Solaris machine; given that Solaris uses some kind of klugy global
variable to store the user password -- or so the comments in auth.c
claim -- maybe it'd actually work there.)

Did you ever get pam_unix.so to work with PostgreSQL? This whole thing
strikes me as very strange -- especially since every other pam
application on my system -- login, su, ssh, etc. -- works just fine, and
since pam_permit.so also causes no problems.

Anyway, thanks again ... and I'll let you know if I ever discover what's
up.

-Charlie

On Thu, 2003-02-13 at 00:06, Stef wrote:
> Hi Charles,
>
> I can't post to the list due to the smtp checks.
> I've had the same problem before, and the most
> information I could gather, was that it was a bug
> in the 7.2.1 libpq auth.c
>
> Well , I assume when you go pg_config --configure,
> you will have "--with-pam" there, which means your
> postgres was compiled with pam support.
>
> Well, even if it wasn't, I don't think you will be able to
> fix this without recompiling postgres. You will need to replace
> from the 7.2.1 source :
> ...src/backend/libpq/auth.c
> with the auth.c in 7.3.1, or you can hack it yourself.
> It is quite easy if you look at the pam manpages in solaris
> etc. You can either reinstall postgres, or you can just compile
> it and change the libpq library. The latter being something
> not even I would try :)
>
> Well anyway, good luck!!
>
> On 11 Feb 2003 15:53:00 -0800
> Charles Hornberger <charlie@hss.caltech.edu> wrote:
>
> => I'm just following up on my begging last Friday re PAM and PostgreSQL
> => from ... with more begging. As I mentioned last time, I've seen this
> => problem mentioned before but have never seen it solved. Is there simply
> => no solution? Is there some obvious, stupid mistake I'm making? Has
> => anyone out there actually managed to get PAM authentication (via
> => pam_unix.so) working?
> =>
> => Thanks (again) in advance for any help, hints, tips, advice, words of
> => sympathy, etc.
> =>
> => -Charlie
> =>
> => On Fri, 2003-02-07 at 17:12, Charles Hornberger wrote:
> => > Hello --
> => >
> => > I'm trying to get PostgreSQL to use PAM for authentication and hitting a
> => > big, blank brick wall. I'd appreciate any advice anyone can give. (What
> => > I'm trying to accomplish is to allow regular users to connect to the
> => > database server from elsewhere on the network using their existing
> => > system password on the server.)
> => >
> => > The database server (192.168.0.1) is running PostgreSQL 7.2.1 on Solaris
> => > 7. In pg_hba.conf, the relevant line is:
> => >
> => >    hostssl    all         192.168.0.2       255.255.255.255  pam
> => >
> => > and /etc/pam.conf contains the following:
> => >
> => >    other   auth     required   /usr/lib/security/pam_unix.so.1
> => >    other   account  required   /usr/lib/security/pam_unix.so.1
> => >    other   session  required   /usr/lib/security/pam_unix.so.1
> => >    other   password required   /usr/lib/security/pam_unix.so.1
> => >
> => > (I've tried using 'postgresql' instead of 'other' as the service name;
> => > it makes no difference.)
> => >
> => > When I try to connect from the client (192.168.0.2), I get the
> => > following:
> => >
> => >    $ psql -h 192.168.0.1 -U charlie template1
> => >    Password:
> => >    psql: FATAL 1:  PAM authentication failed for user "charlie"
> => >
> => > In the postmaster's logfile on the server, I get:
> => >
> => >    2003-02-07 14:49:57 [24198]  DEBUG:  BackendStartup: forked pid=24558
> => >         socket=8
> => >    CheckPAMAuth: pam_authenticate failed: 'Conversation failure'
> => >    2003-02-07 14:49:57 [24558]  FATAL 1:  PAM authentication failed for
> => >         user "charlie"
> => >    2003-02-07 14:49:57 [24558]  DEBUG:  proc_exit(0)
> => >    2003-02-07 14:49:57 [24558]  DEBUG:  shmem_exit(0)
> => >    2003-02-07 14:49:57 [24558]  DEBUG:  exit(0)
> => >    2003-02-07 14:49:57 [24198]  DEBUG:  reaping dead processes
> => >    2003-02-07 14:49:57 [24198]  DEBUG:  child process (pid 24558) exited
> => >         with exit code 0
> => >    2003-02-07 14:50:01 [24198]  DEBUG:  BackendStartup: forked pid=24562
> => >         socket=8
> => >    CheckPAMAuth: pam_authenticate failed: 'Authentication failed'
> => >    2003-02-07 14:50:01 [24562]  FATAL 1:  PAM authentication failed for
> => >         user "charlie"
> => >    2003-02-07 14:50:01 [24562]  DEBUG:  proc_exit(0)
> => >    2003-02-07 14:50:01 [24562]  DEBUG:  shmem_exit(0)
> => >    2003-02-07 14:50:01 [24562]  DEBUG:  exit(0)
> => >    2003-02-07 14:50:01 [24198]  DEBUG:  reaping dead processes
> => >    2003-02-07 14:50:01 [24198]  DEBUG:  child process (pid 24562) exited
> => >         with exit code 0
> => >
> => > I see identical behaviour with a Debian 3.0 box (this one running
> => > 7.2.3), with one difference: If I change pam_unix.so to pam_permit.so,
> => > it works just fine. So it seems the PAM is working fine, but that
> => > pam_unix.so is not. (There's no pam_permit.so module installed on the
> => > Solaris box, so I can't test this to see if -- as I suspect -- it's true
> => > there, too.)
> => >
> => > On the Debian box, I see the following messages in /var/log/auth.log
> => > when using pam_unix.so:
> => >
> => >    Feb  7 15:10:42 chornberger-0 su(pam_unix)[29522]: authentication
> => >         failure; logname= uid=1000 euid=0 tty=pts/4 ruser=charlie
> => >         rhost=  user=root
> => >    Feb  7 15:10:44 chornberger-0 su[29522]: pam_authenticate:
> => >         Authentication failure
> => >
> => > Alas, I get no such feedback on the Solaris box.
> => >
> => > Thanks in avance for any help ...
> => >
> => > -Charlie
> => >
> => > P.S. I see that this question has been asked before, recently and
> => > repeatedly:
> => >
> => >   http://archives.postgresql.org/pgsql-admin/2002-05/msg00075.php
> => >   http://archives.postgresql.org/pgsql-admin/2002-05/msg00233.php
> => >   http://archives.postgresql.org/pgsql-admin/2002-06/msg00110.php
> => >   http://archives.postgresql.org/pgsql-admin/2002-08/msg00281.php
> => >   http://archives.postgresql.org/pgsql-admin/2002-10/msg00066.php
> => >
> => > But I have yet to stumble across anything that seemed like a solution.
> => > (One person suggested using pam_ftp.so instead of pam_unix.so ... which
> => > doesn't seem like such a hot prospect to me.)
> => >
> => > There was another suggestion at
> => >
> => >   http://archives.postgresql.org/pgsql-patches/2002-12/msg00033.php
> => >
> => > that PAM authentication failures might have something to do with
> => > MD5-encrypted passwords in pg_shadow, but I can't understand how the
> => > contents of pg_shadow would affect PAM authentication. In any case, I
> => > haven't tried applying the patch that was provided there. Should I?
> => --
> => Charles Hornberger <charlie@hss.caltech.edu>
> =>
> =>
> => ---------------------------(end of broadcast)---------------------------
> => TIP 4: Don't 'kill -9' the postmaster
--
Charles Hornberger <charlie@hss.caltech.edu>


В списке pgsql-admin по дате отправления:

Предыдущее
От: Jeremy Buchmann
Дата:
Сообщение: Install error: invalid value for option 'LC_TIME'
Следующее
От: Tom Lane
Дата:
Сообщение: Re: uppercase = lowercase