Re: Is "trust" really a good default? - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Is "trust" really a good default?
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB34101AECD@Herge.rcsinc.local
Whole thread Raw
In response to Is "trust" really a good default?  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: Is "trust" really a good default?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Is "trust" really a good default?  (Lamar Owen <lowen@pari.edu>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Devrim GUNDUZ
Date:
Subject: Problems logging into CVS server
Next
From: Tom Lane
Date:
Subject: Re: Is "trust" really a good default?