Re: password method in pg_hba.conf fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: manu(at)netbsd(dot)org (Emmanuel Dreyfus)
Cc: pgman(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian), pgsql-general(at)postgresql(dot)org
Subject: Re: password method in pg_hba.conf fails
Date: 2003-03-07 14:38:39
Message-ID: 29976.1047047919@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

manu(at)netbsd(dot)org (Emmanuel Dreyfus) writes:
> I now need to store the
> PostgreSQL superuser password in cleartext in a shell script.

The new ~/.pgpass mechanism should help with that.

> I'm ready to work on patches to re-introduce the feature, would you
> accept them?

No. We are trying to get away from using crypt(), mainly because it's
not very portable (and not even very secure these days). And the
secondary-password-file mechanism was never anything more than a kluge
anyway. If you want your database users to be actual Unix system users,
why not just check them directly against /etc/passwd?

> I thought about implementing a PAM for this, since 7.3 supports
> PAM. What do you think about it?

The whole point of PAM is to allow installation-local authentication
methods, so you could easily set up something that checks a password
against /etc/passwd if you like. (There is surely such a PAM module
out there already, I'd expect, so look before you write.)

If your OS supports it, you might also want to consider using
Unix-socket-IDENT authentication, and forget passwords altogether.

regards, tom lane

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-03-07 14:54:57 Re: Why are queries with subselects so slow?
Previous Message Greg Sabino Mullane 2003-03-07 14:15:13 Website advertisements