Re: Is "trust" really a good default?

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is "trust" really a good default?
Date: 2004-07-12 21:10:44
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AECD@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-07-12 21:27:23 Re: Is "trust" really a good default?
Previous Message Devrim GUNDUZ 2004-07-12 20:45:49 Problems logging into CVS server