"Andrew Hammond" <[EMAIL PROTECTED]> writes: > On 6/25/07, Tom Lane <[EMAIL PROTECTED]> wrote: >> +1 on having such a discussion in the manual (someone else suggested >> that already IIRC). But I'm not seeing what a configure flag brings >> to the party.
> Like Andrew Sullivan said above, if we want to achieve the dubious > goal of being "secure by default" this seems like the least invasive > way to change the process so that we can be buzzword compliant. It still wouldn't make us "secure by default". Not unless you propose to actually change the default. In any case, what is "secure by default"? The current default configuration is entirely secure against outside attacks, because it doesn't even allow outside connections. As for inside connections, "secure" is still largely dependent on what your threat model is. The paper that started this whole thread pointed out that "ident" auth can expose you to problems even over a Unix socket, given the right set of conditions. Shall we reject "ident" as not being sufficiently secure? Better get rid of Kerberos, too, since that depends on an outside server that could be compromised. And MD5 is certainly not good enough, since PG doesn't force you to change to a new 12-character not-in-the-dictionary password every week. Any of these things could be considered to be not secure enough, depending on the user's situation. I'm all for providing a more thorough discussion of these matters in the manual. I'm not for changing the default behavior, nor for throwing another roadblock into a day-zero newbie's experience with Postgres. Ultimately it's the user's responsibility to determine what is adequately secure for him. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq