tom lane wrote:
> The bottom line to my mind is that if there were a one-size-fits-all
> authentication solution, we'd not have so many to choose from.  I
don't
> think we are doing DBAs any service by pretending that they might not
> need to think about their choice of auth method.  I could make a good
> case that the initial entry ought to be REJECT, so that you get
nothing
> at all until you've adjusted pg_hba.conf ...

The approach towards security from the default installation seems a
little inconsistent, and inconsistency could lead to complacency and
danger.  The server is default configured to not allow root execution,
which is a very good feature, but might lead one to believe that the
default installation is secure.  The win32 people just received a server
drubbing regarding the admin account issue.

However, trust based auth from localhost is very insecure out of the box
because anybody with shell access can root your database...they can even
bring their own psql along for the ride.

IMO, forcing su password at initdb time (allowing blank password with a
very stern warning) and bumping localhost to auth is the right way to
go.  As far as RPM's, etc. I don't think RPM considerations should be
driving security concerns.

Merlin

Mon, 12 Jul 2004 17:10:44 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: Is "trust" really a good default? 
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> IMO, forcing su password at initdb time (allowing blank password with a
> very stern warning) and bumping localhost to auth is the right way to
> go.

This isn't happening for a number of reasons, the most obvious being
that we cannot require initdb to be run interactively.  (That stern
warning will not impress /dev/null.)

			regards, tom lane

Mon, 12 Jul 2004 17:27:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Is "trust" really a good default? 
It has probably be said before, but new users need
to be able to get up and running on their *development*
system quickly.  Throwing new users for a loop with
the password configuration issues would be a problem.

Most people would put up a test server first anyway
in order to check things out and configure as necessary.

--elein

On Mon, Jul 12, 2004 at 05:27:23PM -0400, Tom Lane wrote:
> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > IMO, forcing su password at initdb time (allowing blank password with a
> > very stern warning) and bumping localhost to auth is the right way to
> > go.
> 
> This isn't happening for a number of reasons, the most obvious being
> that we cannot require initdb to be run interactively.  (That stern
> warning will not impress /dev/null.)
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly

Mon, 12 Jul 2004 17:32:34 -0700
elein <elein@varlena.com>
Re: Is "trust" really a good default?
On Monday 12 July 2004 17:10, Merlin Moncure wrote:
> IMO, forcing su password at initdb time (allowing blank password with a
> very stern warning) and bumping localhost to auth is the right way to
> go.  As far as RPM's, etc. I don't think RPM considerations should be
> driving security concerns.

FWIW, the RPMs default to ident authentication, and trust is off.  This is 
however done as a patch to the sample pg_hba.conf.  A command line switch to 
initdb to mung up an ident default would be fine with me, though.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

Tue, 13 Jul 2004 17:48:00 -0400
Lamar Owen <lowen@pari.edu>
Re: Is "trust" really a good default?