On Mon, Jun 11, 2012 at 06:21:43PM +0200, Magnus Hagander wrote: > On Mon, Jun 11, 2012 at 6:14 PM, David Fetter <da...@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 <da...@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, <da...@fetter.org> wrote: > >> >> > The following bug has been logged on the website: > >> >> > > >> >> > Bug reference: 6687 > >> >> > Logged by: David Fetter > >> >> > Email address: da...@fetter.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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs