Thread: BUG #6687: initdb -A ident can almost never be correct
The following bug has been logged on the website: Bug reference: 6687 Logged by: David Fetter Email address: david@fetter.org PostgreSQL version: 9.1.4 Operating system: All Description:=20=20=20=20=20=20=20=20 When calling initdb -A, it is assumed--wrongly in the case of ident, that every method is valid for both local and network.
On Mon, Jun 11, 2012 at 5:14 PM, <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 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? --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/
On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote: > On Mon, Jun 11, 2012 at 5:14 PM, <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 ident, th= at > > every method is valid for both local and network. >=20 > Um, what do you mean? >=20 > If I specify initdb -A, it gives me peer on local and ident on tcp, is > that not what you expected? >=20 > 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. I'm tempted to say it's always wrong for network access, only I know someone will pipe up and talk about how they're running identd on some legacy system. 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
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 ident, t= hat >> > 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. =A0This 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 can get the argument for "peer", which could potentially leave the non-local entries out completely. But I don't see anything wrong with what "ident" does. And even in the case of peer, since the default is not to even *listen* on remote connections, it's not a huge problem... --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/
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 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. =A0This 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. >=20 > 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. 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. 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
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 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. =A0This 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). =A0That 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. =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. So what interface *would* you suggest? --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/
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
David Fetter <david@fetter.org> writes:
> 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.
This is nonsense. As Magnus said, localhost is the one case where
identd *can* be trusted. There is no reason that we should discriminate
against that case.
It also does not seem to me like a good plan to insist that identd be
running at the same instant initdb runs; it's not hard to think of
installation scenarios where that won't be true.
regards, tom lane