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:
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: 6687
Logged by: David Fetter
Email address: david@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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: 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: 6687
Logged by: David Fetter
Email address: david@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.
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.
--
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, <david@fetter.org> wrote:
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: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 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...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: 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, <david@fetter.org> wrote:
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: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.
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.
--
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, <david@fetter.org> wrote:
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: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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: 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, <david@fetter.org> wrote:
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: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@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