password method in pg_hba.conf fails

Emmanuel Dreyfus <manu@netbsd.org> writes:

I had an external password file ~pgsql/data/pg_passwd with lines like this:
guest:OgP29.PYhgA

We do not support external password files anymore. Sorry.

regards, tom lane

manu@netbsd.org (Emmanuel Dreyfus) writes:

We do not support external password files anymore. Sorry.

What is the benefit of throwing away this feature?

I don't recall the reasoning. You can dig through the pghackers mailing
list archives if you want to see the discussion.

regards, tom lane

Tom Lane wrote:

manu@netbsd.org (Emmanuel Dreyfus) writes:

We do not support external password files anymore. Sorry.

What is the benefit of throwing away this feature?

I don't recall the reasoning. You can dig through the pghackers mailing
list archives if you want to see the discussion.

The issue is that no one was using it, or at least we thought so, and it
could only use crypt, while MD5 is better because it allows random salt
to be added to the over-the-wire password transfer.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

manu@netbsd.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

Tom Lane wrote:

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.

Right. If you are using unix socket, they have already logged in, and
'local ident' allow you to know for sure who is on the other end of the
socket.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Emmanuel Dreyfus wrote:

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

Most of the story is going on through httpd, so this won't help, the
user is www, whatever the real user is.

However, last time I checked, UNIX socket ident was not available on
NetBSD. I'll really have to add support for this some day.

It has been available for NetBSD since 7.2. OpenBSD is only added in 7.4.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073