Robert Treat <xzilla@users.sourceforge.net> writes:
> I am sure Chris would back me up on saying that the inability to
> authenticate a database connection is the #1 support problem on the
> phppgadmin mailing lists.... and you want to make this harder for
> people??
The other thing that bothers me about this proposal is that password
auth is certainly the least convenient-to-use auth method we have,
and it encourages insecure practices like coding passwords right into
access scripts. So I'm not pleased with the idea of making it the
default. For local-access-only installations, either IDENT or
socket-file-permissions-based access control is likely to be a much more
usable choice, but I don't think we can usefully make either of those
the default either. So it still comes down to the DBA having to make a
conscious choice.
If what you want to do is raise the visibility of the need to make that
choice, we could do something like this:
initdb --trust installs pg_hba.conf with TRUST local auth, same as nowinitdb with -W or --pwfile installs
pg_hba.confwith MD5 local authinitdb with no relevant switch installs pg_hba.conf with REJECT local auth
thus forcing the DBA to make some choice before he can do anything.
We could also add initdb --ident to install with IDENT local auth,
which would be a cleaner solution for the distros that are currently
enforcing that policy via a patch to pg_hba.conf.sample.
I suspect however that we'd wind up reverting the whole thing before
we get out of beta, because one thing I guarantee you is there will
be lots of complaints.
The only part of this discussion that I'd really be prepared to buy into
is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
with MD5 as the default auth (because that's probably what the user
wants anyway). But otherwise I think we should leave initdb's behavior
alone. I do not agree with trying to force people to use passwords.
regards, tom lane