initdb authentication

Magnus Hagander wrote:

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. And I certainly don't like forcing
extra switches on users that just try out an installation locally.

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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Magnus Hagander wrote:

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. And I certainly don't like forcing
extra switches on users that just try out an installation locally.

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. 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.

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Thu, Jul 15, 2004 at 11:20:46PM +0200, Peter Eisentraut wrote:

Magnus Hagander wrote:

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. And I certainly don't like forcing
extra switches on users that just try out an installation locally.

I agree with this sentiment. On the spanish list is common to see
people trying to do things on an RPM-installed server, which is
configured to use IDENT by default, and asking why they cannot connect.
The answer is always to look at pg_hba.conf and the relevant
documentation.

If it were my choice, I'd disallow connections by default completely,
and spit a reject message along the lines of "you should have a look at
pg_hba.conf".

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Uno combate cuando es necesario... �no cuando est� de humor!
El humor es para el ganado, o para hacer el amor, o para tocar el
baliset. No para combatir." (Gurney Halleck)

Bruce Momjian <pgman@candle.pha.pa.us> writes:

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. If I am on an insecure machine, the window if time between
initdb and editing of pg_hba.conf is pretty bad.

Bruce, you of all people should be aware that there is no such window.
The postmaster *is not running* and cannot accept any hostile
connections if you haven't started it.

Argue all you like about the potential for novice error, but don't try
to scare us by claiming that it's inherently insecure.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

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. If I am on an insecure machine, the window if time between
initdb and editing of pg_hba.conf is pretty bad.

Bruce, you of all people should be aware that there is no such window.
The postmaster *is not running* and cannot accept any hostile
connections if you haven't started it.

Argue all you like about the potential for novice error, but don't try
to scare us by claiming that it's inherently insecure.

Ah, I forgot about postmaster start. (My scripts do it automatically
here.) Maybe we just need to print a warning telling people they should
secure pg_hba.conf before starting the postmaster on an insecure
machine.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

Here's a version of this patch that includes documentation updates.

//Magnus

I got a new idea on this. I think we should add an initdb option that
takes a string to specify the local authentication method:

initdb --localauth 'ident'

or whatever the user wants. I think this is more flexible and more
compact. It would default to 'trust', and the packagers could set it to
whatever they want. If their OS supports local ident, they can use
that.

Also keep in mind you might want some ident map file:

initdb --localauth 'ident mymap'

so you would need to allow multiple words in the string.

---------------------------------------------------------------------------

Magnus Hagander wrote:

Here's a version of this patch that includes documentation updates.

//Magnus

-----Original Message-----
From: Magnus Hagander
Sent: den 15 juli 2004 23:02
To: pgsql-patches@postgresql.org
Subject: [PATCHES] initdb authentication

Ok, here is one more try at the initdb default authentication stuff.
This one adds the switches "--ident" and "--trust", which will
configure
pg_hba.conf with ident and trust authentication respectively. If trust
authentication is selected, a warning is written to
pg_hba.conf. The old
switches for password prompt/file still apply.

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..)

Oh, and this time, the comments are updated :-)

//Magnus

Content-Description: initdb_auth.patch

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Ok, here is another one.

Doc patches coming up if/when this one is approved.

//Magnus

Magnus Hagander wrote:

Ok, here is another one.

Doc patches coming up if/when this one is approved.

//Magnus

+       /* Kerberos methods not listed because they are not supported
+        * over local connections and are rejected in hba.c */

Is this true of all local connections, or only Unix socket connections?
After all, this patch adjusts one 'local' line and 2 'host' lines. Maybe
we would just need to tell people that if they want Kerberos they would
have to do it by hand, rather than using this flag.

cheers

andrew

I assume he means 'local' lines in the config file, not local INET
connections. Maybe local needs quotes

---------------------------------------------------------------------------

Andrew Dunstan wrote:

Magnus Hagander wrote:

Ok, here is another one.

Doc patches coming up if/when this one is approved.

//Magnus

+       /* Kerberos methods not listed because they are not supported
+        * over local connections and are rejected in hba.c */

Is this true of all local connections, or only Unix socket connections?
After all, this patch adjusts one 'local' line and 2 'host' lines. Maybe
we would just need to tell people that if they want Kerberos they would
have to do it by hand, rather than using this flag.

cheers

andrew

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Ok, here is another one.

Doc patches coming up if/when this one is approved.

//Magnus

+       /* Kerberos methods not listed because they are not supported
+        * over local connections and are rejected in hba.c */

Is this true of all local connections, or only Unix socket
connections?
After all, this patch adjusts one 'local' line and 2 'host'
lines. Maybe
we would just need to tell people that if they want Kerberos
they would
have to do it by hand, rather than using this flag.

It's true of 'local', meaning Unix socket connections.

Something along that line about kerberos should go in the docs, yes :-)

//Magnus

Magnus Hagander wrote:

Ok, here is another one.

Doc patches coming up if/when this one is approved.

I think this warning is seriously going to annoy me. Can we do without
it?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Magnus Hagander wrote:

Ok, here is another one.

Doc patches coming up if/when this one is approved.

I think this warning is seriously going to annoy me. Can we do without
it?

What if we skip the warning if the user specifically asks for 'trust'?
Would that help?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Ok, here is another one.

Doc patches coming up if/when this one is approved.

I think this warning is seriously going to annoy me. Can we do
without it?

What if we skip the warning if the user specifically asks for
'trust'?
Would that help?

Uh. That's how it's done. The warning is only printed if you don't
specifically pick a method.

As for the original question, yes, we can of course do without it. But I
think we shouldn't.
I still say people will get a lot less annoyed by this one than for
example the no-run-as-admin on win32. And this is just a *warning* after
all, it will install the database just fine. Or just add "-A trust".

//Magnus

Patch applied. Thanks.

I just cleaned up some of the code formatting.

---------------------------------------------------------------------------

Magnus Hagander wrote:

Ok, here is another one.

Doc patches coming up if/when this one is approved.

//Magnus

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: den 17 juli 2004 03:11
To: Magnus Hagander
Cc: pgsql-patches@postgresql.org
Subject: Re: [PATCHES] initdb authentication

I got a new idea on this. I think we should add an initdb option that
takes a string to specify the local authentication method:

initdb --localauth 'ident'

or whatever the user wants. I think this is more flexible and more
compact. It would default to 'trust', and the packagers could
set it to
whatever they want. If their OS supports local ident, they can use
that.

Also keep in mind you might want some ident map file:

initdb --localauth 'ident mymap'

so you would need to allow multiple words in the string.

---------------------------------------------------------------
------------

Magnus Hagander wrote:

Here's a version of this patch that includes documentation updates.

//Magnus

Content-Description: initdb_auth.patch

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073