Re: initdb authentication - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: initdb authentication
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE1716D7@algol.sollentuna.se
Whole thread Raw
In response to initdb authentication  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-patches
> > > This one makes it mandatory to pick some kind of
> authentication. If
> > > that's not wanted, it's easy to change it to default to
> trust (which
> > > I think is wrong, but we've been through that already..)
> >
> > I don't think I like any of this.  Sooner rather than later, people
> > need to look at pg_hba.conf and think about it.  I don't
> like switches
> > that induce them to skip that step.

My guess is that a whole lot (I'd go as far as to say most) users don't
do this. Instead they start the system in whatever is default, *and
think it's secure enough*. Therefor, the default should be a reasonable
guess at the securest thing they want. And setting "trust" is not that.

Sort of like MSSQL permitting and defaulting to a blank sa password in
earlier versions. Even MS fixed that. Yes, it took a worm for them to do
it, but they did...

If you want to fix that the whole way, install a pg_hba.conf *without
anything*. That way nobody can connect and use their database until they
edit it.
(Turns out that is the same thing my patch does except it lets you set
it on the commandline to initdb instead of having to edit the file
assuming you just want local auth)

> > And I certainly don't like
> > forcing extra switches on users that just try out an
> > installation locally.

Oh, you mean along the line of having to create a separate user account
to run it under? I'd say that is a whole lot more work than just
entering a password. Or *explicitly* chosing that you want trust
authentication.

This very argument was shot down pretty quickly last time it came up in
just a slightly different context, but it keeps popping up...


> > I would be in favor of making everything supertight and secure by
> > default, no questions asked.  The is a definable goal.  But
> as long as
> > there is no agreement on that, let's not create illusions in that
> > direction while inconveniencing a bunch of people for little gain.
>
> I think the basic problem is that right now there is no way
> to do an initdb and have it be secure _before_ you edit
> pg_hba.conf.  That isn't acceptable.

My thoughts exactly. Because most users *will not* edit pg_hba.conf
until they need it to enable something, this is a problem.


> If I am on an insecure
> machine, the window if time between initdb and editing of
> pg_hba.conf is pretty bad.  I could edit pg_hba.conf.sample,
> but then I am editing a sample file.

Um. No. initdb does not start the database. You're safe until you start
postmaster. This is defence against the fact that most users will start
the database without editing (or looking at, or for that matter even be
aware of the existance of) pg_hba.conf.


> I think Magnus's patch takes us closer to secure.  I do agree
> that by default we shouldn't require any flag and install
> unsecure and issue a warning.

I say that warning should be in the form of "if you realy want this,
append --trust to the command you just issued", but any step towards it
is a step in the right direction :-)


//Magnus


pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: [subxact] Proof-of-concept: report nest level to client
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: add missing options to pg_dumpall