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: