Re: Bugtraq: Having Fun With PostgreSQL

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Tom Lane wrote:
>>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>>> One thing I've thought about doing is to remove the default in initdb
>>>> completely and *force* the user to choose auth type.
>
>>> I'll object if no one else does: this will break existing installation
>>> habits and processes to no real benefit.
>
>> The benefit would be that PostgreSQL would be "secure by default". Which
>> we are *not* today.
>
> No, we would NOT be "secure by default". We'd only be secure by default
> if we forced the user to pick a secure auth method, for whatever value
> of "secure" is politically correct.

Good point. But we'd at least force the user to read up on things. (Or
guess, but there's nothing we can do about that at all)

> A change like this will make exactly 0 difference to users of
> prepackaged installations, since AFAIK all packages make their own
> decisions about what default auth method to use (and since they are
> targeting specific platforms, they have more context to make this choice
> than we do).

Agreed.

> It will also be useless and annoying to experienced users
> of the source code, since they already know what to do.

Well, it would help them not to forget an important step, but agreed in
principle.

> The only group
> that will be affected will be newbie installers-from-source (which I
> bet is a mighty small group these days). And those people will find
> that Postgres' first demand on them is to read and understand some
> rather complex documentation to try to pick a default auth method.
> You really think that this group is particularly likely to get it right?
> If it were an open-and-shut decision we'd probably just move to a
> non-trust default.

In that case, md5 would seem to be the reasonable choice - unless we
want something platform specific somehow set by autoconf or so (I'd say
ident sameuser over unix sockets make a lot of sense on platforms that
support it).

> I would also argue that trust auth is not such an evil option that we
> mustn't allow it to be the default. On a single-user machine it's
> actually perfectly sane, seeing that we don't allow TCP connections
> by default.

Is there really such a thing as a single-user machine running
PostgreSQL? Maybe single "human user", but if you're not running some
other services on it (webserver, mailserver, whatever) it's not very
likely to be running pg, I think.

> I think what this change would mostly do is put still another barrier
> in the way of people trying out Postgres. There's already a darn steep
> learning curve; we don't need a cliff at the very start.

Didn't we just say that these users are most likely running a
pre-packaged version anyway?

Either way, it's not critical, given that the majority of our users use
some kind of pre-packaged deal, but I still think we could do better.

Out of curiosity, how do other databases deal with this? The only one
I've been installing recently is MSSQL which basically lets you chose
between SSPI
(ident-sameuser-over-sockets-and-kerberos-over-network-equivalent) or
password (md5 equivalent, AFAIK). It does *not* let you use empty
passwords, which is what would be equivalent with our "trust".

//Magnus