Re: BUG #6687: initdb -A ident can almost never be correct

On Mon, Jun 11, 2012 at 06:21:43PM +0200, Magnus Hagander wrote:
> On Mon, Jun 11, 2012 at 6:14 PM, David Fetter <david@fetter.org> wrote:
> > On Mon, Jun 11, 2012 at 06:04:22PM +0200, Magnus Hagander wrote:
> >> On Mon, Jun 11, 2012 at 6:01 PM, David Fetter <david@fetter.org> wrote:
> >> > On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote:
> >> >> On Mon, Jun 11, 2012 at 5:14 PM, =A0<david@fetter.org> wrote:
> >> >> > The following bug has been logged on the website:
> >> >> >
> >> >> > Bug reference: =A0 =A0 =A06687
> >> >> > Logged by: =A0 =A0 =A0 =A0 =A0David Fetter
> >> >> > Email address: =A0 =A0 =A0david@fetter.org
> >> >> > PostgreSQL version: 9.1.4
> >> >> > Operating system: =A0 All
> >> >> > Description:
> >> >> >
> >> >> > When calling initdb -A, it is assumed--wrongly in the case of ide=
nt, that
> >> >> > every method is valid for both local and network.
> >> >>
> >> >> Um, what do you mean?
> >> >>
> >> >> If I specify initdb -A, it gives me peer on local and ident on tcp,=
 is
> >> >> that not what you expected?
> >> >>
> >> >> Or maybe I'm misunderstanding the problem completely.. What is
> >> >> happening, and what are you expecting to happen?
> >> >
> >> > We have a design issue, namely that initdb -A blindly applies the au=
th
> >> > method specified to all default accesses. =A0This is the correct
> >> > behavior for all auth methods except for ident, where it is wrong ju=
st
> >> > about everywhere for network (localhost rather than local) access.
> >>
> >> Uh, what *would* you expect to happen if you choose "ident"? That
> >> something different than what you choose is done?
> >
> > I'd expect it to error out because it's trying to apply ident to
> > things which to an excellent approximation can never work, namely
> > localhost (ipv4 and ipv6 versions). =A0That this misbehavior is
> > long-standing doesn't make it correct.
>=20
> I've certainly seen deployments over localhost that use that. In fact,
> that's one of the few cases where ident can be considered "fully
> secure", given that the channel is actually trusted...
>=20
> So erroring out is clearly not the right thing. That's not saying that
> the interface can't be improved, but erroring out is not an
> improvement.
>=20
>=20
> > This came up in IRC with someone trying to create automated deployment
> > scripts using initdb -A and then connecting to localhost instead of
> > local. =A0You could argue that this is pilot error, but it's a perfectly
> > reasonable thing for someone new to try, but there is nothing to
> > indicate the source of the problems he's seeing.
>=20
> So what interface *would* you suggest?

Interface wouldn't change.  Instead, it would check for your
once-in-a-blue-moon scenario of identd answering on the network and
error out if it didn't fine same.

Cheers,
David.
--=20
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate