Indent authentication overloading
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over tcp? does *anybody* use that
intentionally today?)
Should we not consider naming those two different things?
If not now, then at least put it on the TODO of things to do the next
time we need to break backwards compatibility with the format of
pg_hba.conf? Though if we're going to break backwards compatibility
anywhere, pg_hba is probably one of the least bad places to do it...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over tcp? does *anybody* use that
intentionally today?)
Should we not consider naming those two different things?
Maybe, but it seems like the time to raise the objection was six or
eight years ago :-(. Renaming now will do little except to introduce
even more confusion.
regards, tom lane
On Wed, Nov 17, 2010 at 16:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over tcp? does *anybody* use that
intentionally today?)Should we not consider naming those two different things?
Maybe, but it seems like the time to raise the objection was six or
eight years ago :-(. Renaming now will do little except to introduce
even more confusion.
For existing users, yes.
For new users, no.
I certainly get comments on it pretty much every time I do training
that includes explaining pg_hba options.
The question is if it's worth confusing our existing users a little,
at the advantage of not confusing new users. We could of course also
just drop ident-over-tcp completely, but there might be some poor guy
out there who actually *uses* it :-)
And I agree it would've been much better to do it years ago. That
doesn't mean we shouldn't at least *consider* doing it at some point.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Nov 17, 2010 at 04:43:00PM +0100, Magnus Hagander wrote:
On Wed, Nov 17, 2010 at 16:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being
one of the most secure options we have, the other one being one
of the most *insecure* ones (really? ident over tcp? does
*anybody* use that intentionally today?)Should we not consider naming those two different things?
Maybe, but it seems like the time to raise the objection was six
or eight years ago :-(. �Renaming now will do little except to
introduce even more confusion.For existing users, yes. For new users, no.
Yep. If we're to be a successful project, the vast majority of our
users are future users, not current or past ones.
I certainly get comments on it pretty much every time I do training
that includes explaining pg_hba options.The question is if it's worth confusing our existing users a little,
at the advantage of not confusing new users. We could of course also
just drop ident-over-tcp completely, but there might be some poor
guy out there who actually *uses* it :-)
+1 for dropping it completely. We have dropped features--automatic
cast to TEXT, for example--that a good deal more of our user base
relied on, for reasons less compelling than this.
And I agree it would've been much better to do it years ago. That
doesn't mean we shouldn't at least *consider* doing it at some
point.
The sooner, the better, IMHO.
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 2010-11-17 22:43, Magnus Hagander wrote:
at the advantage of not confusing new users. We could of course also
just drop ident-over-tcp completely, but there might be some poor guy
out there who actually *uses* it :-)
As far as I know, companies do use it in their internal networks where
they do have a reasonable shot at full control over ident connections.
I don't know how easy it would be for them to switch to other methods.
Jeroen
On ons, 2010-11-17 at 16:35 +0100, Magnus Hagander wrote:
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over tcp? does *anybody* use that
intentionally today?)Should we not consider naming those two different things?
The original patch called the Unix domain socket version "peer" (whereas
the name "ident" comes from the official name of the TCP/IP protocol
used). You can look it up in the archives, but I believe the argument
for using the name "ident" for both was because "ident" was established
and the new feature would provide the same functionality.
That said, I completely agree with you. Every time I look through a
pg_hba.conf I think, that's a terrible name, we should rename this.
We could perhaps introduce an alternative name and slowly deprecate the
original one.
On Wed, Nov 17, 2010 at 17:10, Jeroen Vermeulen <jtv@xs4all.nl> wrote:
On 2010-11-17 22:43, Magnus Hagander wrote:
at the advantage of not confusing new users. We could of course also
just drop ident-over-tcp completely, but there might be some poor guy
out there who actually *uses* it :-)As far as I know, companies do use it in their internal networks where they
do have a reasonable shot at full control over ident connections. I don't
know how easy it would be for them to switch to other methods.
Yea, I think deleting it is going a bit overboard.
If it was a matter of changing it for those who use ident over tcp, I
really wouldn't hesitate - they're few :-) But the problem is that
it's the ident-over-tcp that's correctly named, not the other one...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Nov 17, 2010 at 17:31, Peter Eisentraut <peter_e@gmx.net> wrote:
On ons, 2010-11-17 at 16:35 +0100, Magnus Hagander wrote:
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over tcp? does *anybody* use that
intentionally today?)Should we not consider naming those two different things?
The original patch called the Unix domain socket version "peer" (whereas
the name "ident" comes from the official name of the TCP/IP protocol
used). You can look it up in the archives, but I believe the argument
for using the name "ident" for both was because "ident" was established
and the new feature would provide the same functionality.
Yeah, I vaguely recall that discussion - too lazy to actually look it
up :-) I think the argument was definitely wrong, but it didn't seem
so at the time...
That said, I completely agree with you. Every time I look through a
pg_hba.conf I think, that's a terrible name, we should rename this.We could perhaps introduce an alternative name and slowly deprecate the
original one.
That seems reasonable. Maybe even have the server emit a warning when
it sees it (since we now read/parse pg_hba.conf on server start, it
would only show up once per server reload, not on every connect). Or
maybe just doc-deprecate in 9.1, warning in 9.2, drop in 9.3 or
something?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
If it was a matter of changing it for those who use ident over tcp, I
really wouldn't hesitate - they're few :-) But the problem is that
it's the ident-over-tcp that's correctly named, not the other one...
Yeah, renaming the TCP version would be quite wrong. If we're going to
do something about this, I agree with Peter's suggestion: add "peer" as
the preferred name for the Unix-socket method, and deprecate but don't
remove "ident".
regards, tom lane
On 2010-11-18 00:14, Magnus Hagander wrote:
If it was a matter of changing it for those who use ident over tcp, I
really wouldn't hesitate - they're few :-) But the problem is that
it's the ident-over-tcp that's correctly named, not the other one...
True.
By the way ISTR we don't fall back to identd for TCP connections alone.
I saw it documented somewhere that we also talk to identd on operating
systems that won't tell us who's on the other end of the socket. Are
those still out there?
Jeroen
On Wed, Nov 17, 2010 at 10:35 PM, Magnus Hagander <magnus@hagander.net> wrote:
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over tcp? does *anybody* use that
intentionally today?)
We use it. Do you have an alternative that doesn't lower security
besides Kerberos? Anti-ident arguments are straw man arguments - "If
you setup identd badly or don't trust remote root or your network,
ident sucks as an authentication mechanism".
Ident is great as you don't have to lower security by dealing with
keys on the client system (more management headaches == lower
security), or worry about those keys being reused by accounts that
shouldn't be reusing them. Please don't deprecate it unless there is
an alternative. And if you are a pg_pool or pgbouncer maintainer,
please consider adding support :)
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
We use it. Do you have an alternative that doesn't lower security
besides Kerberos? Anti-ident arguments are straw man arguments - "If
you setup identd badly or don't trust remote root or your network,
ident sucks as an authentication mechanism".
Actually, you're trusting that nobody can add their own machine as a
node on your network. All someone has to do is plug their linux laptop
into a network cable in your office and they have free access to the
database.
Ident is great as you don't have to lower security by dealing with
keys on the client system (more management headaches == lower
security), or worry about those keys being reused by accounts that
shouldn't be reusing them. Please don't deprecate it unless there is
an alternative. And if you are a pg_pool or pgbouncer maintainer,
please consider adding support :)
I don't think anyone is talking about eliminating it, just
distinguishing ident-over-TCP from unix-socket-same-user, which are
really two different authentication mechanisms.
HOWEVER, I can't see any way of doing this which wouldn't cause a
significant amount of backwards-compatibility confusion. Given that
users can distinguish between local and TCP ident in pg_hba.conf already
(and the default pg_hba.conf does) it is worth the confusion it will cause?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Thu, Nov 18, 2010 at 1:01 PM, Josh Berkus <josh@agliodbs.com> wrote:
We use it. Do you have an alternative that doesn't lower security
besides Kerberos? Anti-ident arguments are straw man arguments - "If
you setup identd badly or don't trust remote root or your network,
ident sucks as an authentication mechanism".Actually, you're trusting that nobody can add their own machine as a node on
your network. All someone has to do is plug their linux laptop into a
network cable in your office and they have free access to the database.
I think you need to give him a little more credit than that... From
the description he gave, I wouldn't be surprised if the networks he's
using ident on, he's got switch ports locked, limited server access,
etc...
His whole point was that in his locked down network, ident is *better*
that giving everybody "yet another password" they have to manage, have
users not mis-manage, and make sure users don't mis-use...
So, yes, ident is only as secure as the *network and machines* it's
used on. Passwords are only as secure as the users managing them, and
the machines/filesystems containing .pgpass ;-)
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Josh Berkus <josh@agliodbs.com> writes:
We use it. Do you have an alternative that doesn't lower security
besides Kerberos? Anti-ident arguments are straw man arguments - "If
you setup identd badly or don't trust remote root or your network,
ident sucks as an authentication mechanism".
Actually, you're trusting that nobody can add their own machine as a
node on your network. All someone has to do is plug their linux laptop
into a network cable in your office and they have free access to the
database.
You're assuming the OP is using ident for wild-card IP ranges rather
than specific IP addresses. I agree that ident is *hard* to set up
securely, but that doesn't mean it's entirely insecure.
I don't think anyone is talking about eliminating it, just
distinguishing ident-over-TCP from unix-socket-same-user, which are
really two different authentication mechanisms.
HOWEVER, I can't see any way of doing this which wouldn't cause a
significant amount of backwards-compatibility confusion.
I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. Is that really too confusing?
regards, tom lane
On Thu, Nov 18, 2010 at 19:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Josh Berkus <josh@agliodbs.com> writes:
We use it. Do you have an alternative that doesn't lower security
besides Kerberos? Anti-ident arguments are straw man arguments - "If
you setup identd badly or don't trust remote root or your network,
ident sucks as an authentication mechanism".Actually, you're trusting that nobody can add their own machine as a
node on your network. All someone has to do is plug their linux laptop
into a network cable in your office and they have free access to the
database.You're assuming the OP is using ident for wild-card IP ranges rather
than specific IP addresses. I agree that ident is *hard* to set up
securely, but that doesn't mean it's entirely insecure.
If you can get on the network, you can take out that single IP as
well, in most networks. (Yes, you can protect against that, but it's
not the default by any means). It takes a little bit more work, but
it's really not that hard.
OTOH, if you can get on the network in *that* way, you should be using
SSL or ipsec.
But I definitely agree that it can be used in secure ways, depending
on the circumstances. If it wans't clear, my "suggestion" to remove it
completely really wasn't serious.
I don't think anyone is talking about eliminating it, just
distinguishing ident-over-TCP from unix-socket-same-user, which are
really two different authentication mechanisms.HOWEVER, I can't see any way of doing this which wouldn't cause a
significant amount of backwards-compatibility confusion.I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. Is that really too confusing?
Yes, that's the current proposal - and also have the system log that
"ident is deprecated, use peer" when it's found in the files.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Thu, Nov 18, 2010 at 19:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. �Is that really too confusing?
Yes, that's the current proposal - and also have the system log that
"ident is deprecated, use peer" when it's found in the files.
Personally I could do without that little frammish. We don't issue
wrist-slaps for other obsolete usages; why single out this one?
It's also warning about the wrong thing. IMO the real subtext to this
discussion is that we're afraid people are using ident-over-TCP
insecurely because they've confused it with ident-over-socket.
Which is a legitimate concern, but issuing warnings about
ident-over-socket configurations will accomplish nothing whatsoever
to wake up the guy at risk, because he's not using one. It will only
make us look like pedantic nannies annoying people whose configurations
are perfectly fine.
regards, tom lane
On 11/18/2010 01:21 PM, Tom Lane wrote:
I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. Is that really too confusing?
Not to me. And I think that's a good proposal.
cheers
andrew
I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. Is that really too confusing?
What about the pg_ident file? Are we going to rename it? Are we
(better) going to have separate files for pg_peer and pg_ident?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Thu, Nov 18, 2010 at 19:41, Josh Berkus <josh@agliodbs.com> wrote:
I thought the proposal on the table was to add "peer" (or some other
name) to refer to the unix-socket auth method, and use that term
preferentially in the docs, while continuing to accept "ident" as an
old name for it. Is that really too confusing?What about the pg_ident file? Are we going to rename it? Are we
We should've done that long ago - it's already used for things that
aren't ident. If anything, it should be pg_usermap.conf.
(better) going to have separate files for pg_peer and pg_ident?
Why? It already supports multiple maps...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
We should've done that long ago - it's already used for things that
aren't ident. If anything, it should be pg_usermap.conf.
That would be nice. How would we handle the backwards compatibility?
Accept pg_ident files also for 2 versions with a warning in the logs,
and then stop reading them?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com