Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Magnus Hagander <[EMAIL PROTECTED]> 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. 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). It will also be useless and annoying to experienced users of the source code, since they already know what to do. 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. 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. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster