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(at)fetter(dot)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(at)fetter(dot)org> wrote:
> >> > On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote:
> >> >> On Mon, Jun 11, 2012 at 5:14 PM,  <david(at)fetter(dot)org> wrote:
> >> >> > The following bug has been logged on the website:
> >> >> >
> >> >> > Bug reference:      6687
> >> >> > Logged by:          David Fetter
> >> >> > Email address:      david(at)fetter(dot)org
> >> >> > PostgreSQL version: 9.1.4
> >> >> > Operating system:   All
> >> >> > Description:
> >> >> >
> >> >> > When calling initdb -A, it is assumed--wrongly in the case of ident, 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 auth
> >> > method specified to all default accesses.  This is the correct
> >> > behavior for all auth methods except for ident, where it is wrong just
> >> > 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).  That this misbehavior is
> > long-standing doesn't make it correct.
>
> 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...
>
> 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.
>
>
> > This came up in IRC with someone trying to create automated deployment
> > scripts using initdb -A and then connecting to localhost instead of
> > local.  You 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.
>
> 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.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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