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(at)hagander(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Magnus Hagander <magnus(at)hagander(dot)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(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

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(at)xs4all(dot)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(at)gmx(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)stuartbishop(dot)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(at)agliodbs(dot)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(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

Josh Berkus <josh(at)agliodbs(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)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(at)hagander(dot)net> writes:
> On Thu, Nov 18, 2010 at 19:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)agliodbs(dot)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

On Thu, Nov 18, 2010 at 6:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Perhaps we should rename both then? Then we could warn if someone is
using ident to refer to identd authentication but not if they're using
it to refer to peer authentication.

--
greg

On Thu, Nov 18, 2010 at 19:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Thu, Nov 18, 2010 at 19:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

Fair enough. I may be guilty of thinking we should do it more often
;), but I agree that being consistent is more important.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Added to TODO:

Rename unix domain socket 'ident' connections to 'peer', to avoid
confusion with TCP 'ident'

* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01053.php

---------------------------------------------------------------------------

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?
>
> 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/
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> Added to TODO:
>
>        Rename unix domain socket 'ident' connections to 'peer', to avoid
>        confusion with TCP 'ident'

Should we consider adding "peer" as an alias for "ident" already in
9.1 (and change the default pg_hba.conf template), and then deprecate
ident for 9.2 and remove it in 9.3 or something? By adding the alias
now (yes, I know it's not in the last CF :P), we can move what's going
to be a long process up one release...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander wrote:
> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > Added to TODO:
> >
> > ? ? ? ?Rename unix domain socket 'ident' connections to 'peer', to avoid
> > ? ? ? ?confusion with TCP 'ident'
>
> Should we consider adding "peer" as an alias for "ident" already in
> 9.1 (and change the default pg_hba.conf template), and then deprecate
> ident for 9.2 and remove it in 9.3 or something? By adding the alias
> now (yes, I know it's not in the last CF :P), we can move what's going
> to be a long process up one release...

Well, we can certainly do that.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>> Added to TODO:
>>
>> Rename unix domain socket 'ident' connections to 'peer', to avoid
>> confusion with TCP 'ident'

> Should we consider adding "peer" as an alias for "ident" already in
> 9.1 (and change the default pg_hba.conf template), and then deprecate
> ident for 9.2 and remove it in 9.3 or something? By adding the alias
> now (yes, I know it's not in the last CF :P), we can move what's going
> to be a long process up one release...

It doesn't strike me as urgent enough to be worth pushing through in a
hurry. We have got plenty to do to get 9.1 out the door already ...

regards, tom lane

On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > Added to TODO:
> >
> > Rename unix domain socket 'ident' connections to 'peer', to avoid
> > confusion with TCP 'ident'
>
> Should we consider adding "peer" as an alias for "ident" already in
> 9.1 (and change the default pg_hba.conf template), and then deprecate
> ident for 9.2 and remove it in 9.3 or something? By adding the alias
> now (yes, I know it's not in the last CF :P), we can move what's going
> to be a long process up one release...

Might as well, if you can get it done soon. The documentation might
need more extensive adjustments.

On Fri, Mar 11, 2011 at 15:36, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
>> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> >
>> > Added to TODO:
>> >
>> >        Rename unix domain socket 'ident' connections to 'peer', to avoid
>> >        confusion with TCP 'ident'
>>
>> Should we consider adding "peer" as an alias for "ident" already in
>> 9.1 (and change the default pg_hba.conf template), and then deprecate
>> ident for 9.2 and remove it in 9.3 or something? By adding the alias
>> now (yes, I know it's not in the last CF :P), we can move what's going
>> to be a long process up one release...
>
> Might as well, if you can get it done soon.  The documentation might
> need more extensive adjustments.

The code itself is pretty easy and localized, AFAICT. Attached is a
patch taht implements "peer" for local connections, and automatically
maps "ident" on local sockets to that (with a log message saying it
did).

If people want this to go in, I'll go over the documentation as well -
as you say, that might need some more changes, but we're not as
time-critical on that (meaning we can keep polishing it through beta).

Also, I'd like to get around to making "initdb -A ident" automatically
put "peer" for local sockets as well, which is not included in this
patch but should be a very simple change.

So. Thoughts?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Mon, Mar 14, 2011 at 5:18 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Mar 11, 2011 at 15:36, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
>>> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> >
>>> > Added to TODO:
>>> >
>>> >        Rename unix domain socket 'ident' connections to 'peer', to avoid
>>> >        confusion with TCP 'ident'
>>>
>>> Should we consider adding "peer" as an alias for "ident" already in
>>> 9.1 (and change the default pg_hba.conf template), and then deprecate
>>> ident for 9.2 and remove it in 9.3 or something? By adding the alias
>>> now (yes, I know it's not in the last CF :P), we can move what's going
>>> to be a long process up one release...
>>
>> Might as well, if you can get it done soon.  The documentation might
>> need more extensive adjustments.
>
> The code itself is pretty easy and localized, AFAICT. Attached is a
> patch taht implements "peer" for local connections, and automatically
> maps "ident" on local sockets to that (with a log message saying it
> did).
>
> If people want this to go in, I'll go over the documentation as well -
> as you say, that might need some more changes, but we're not as
> time-critical on that (meaning we can keep polishing it through beta).
>
> Also, I'd like to get around to making "initdb -A ident" automatically
> put "peer" for local sockets as well, which is not included in this
> patch but should be a very simple change.
>
> So. Thoughts?

The log message is an absolute non-starter. You're going to get that
on every backend startup on Windows, I believe.

Also, the text is not accurate: nothing has been automatically changed
to anything. The pg_hba.conf file is just as it was. You could say
something like "ident" authentication on local socket treated as
"peer", but I think a better idea would be to just remove this message
altogether. I see zero reason to force someone who has a pg_hba.conf
file that they have been using for years and are happy with to make
trivial changes to it on our account, and I'd be perfectly happy to
silently treat ident on a local socket as peer forever, while gently
encouraging the use of the newer term in our documentation.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Mar 14, 2011 at 14:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Mar 14, 2011 at 5:18 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Fri, Mar 11, 2011 at 15:36, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>> On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
>>>> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>> >
>>>> > Added to TODO:
>>>> >
>>>> >        Rename unix domain socket 'ident' connections to 'peer', to avoid
>>>> >        confusion with TCP 'ident'
>>>>
>>>> Should we consider adding "peer" as an alias for "ident" already in
>>>> 9.1 (and change the default pg_hba.conf template), and then deprecate
>>>> ident for 9.2 and remove it in 9.3 or something? By adding the alias
>>>> now (yes, I know it's not in the last CF :P), we can move what's going
>>>> to be a long process up one release...
>>>
>>> Might as well, if you can get it done soon.  The documentation might
>>> need more extensive adjustments.
>>
>> The code itself is pretty easy and localized, AFAICT. Attached is a
>> patch taht implements "peer" for local connections, and automatically
>> maps "ident" on local sockets to that (with a log message saying it
>> did).
>>
>> If people want this to go in, I'll go over the documentation as well -
>> as you say, that might need some more changes, but we're not as
>> time-critical on that (meaning we can keep polishing it through beta).
>>
>> Also, I'd like to get around to making "initdb -A ident" automatically
>> put "peer" for local sockets as well, which is not included in this
>> patch but should be a very simple change.
>>
>> So. Thoughts?
>
> The log message is an absolute non-starter.  You're going to get that
> on every backend startup on Windows, I believe.

No, you're not. Because we don't do unix sockets on windows, for
obvious reasons.

You *would* get it on all RPM based installations, or DEB based
installations, on *unix*, unless the patch to initdb is done (which it
is now actually, just wasn't when I posted)

That said, it can easily be removed.

> Also, the text is not accurate: nothing has been automatically changed
> to anything.  The pg_hba.conf file is just as it was.  You could say
> something like "ident" authentication on local socket treated as
> "peer", but I think a better idea would be to just remove this message
> altogether.  I see zero reason to force someone who has a pg_hba.conf
> file that they have been using for years and are happy with to make
> trivial changes to it on our account, and I'd be perfectly happy to
> silently treat ident on a local socket as peer forever, while gently
> encouraging the use of the newer term in our documentation.

The idea being to let people know it's been deprecated, nothing else.
But sure, we can just remove the message - at elast for now, and maybe
add it $n releases down the road when people are expected to have
changed over.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Mon, Mar 14, 2011 at 14:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Also, the text is not accurate: nothing has been automatically changed
>> to anything. The pg_hba.conf file is just as it was. You could say
>> something like "ident" authentication on local socket treated as
>> "peer", but I think a better idea would be to just remove this message
>> altogether.

> The idea being to let people know it's been deprecated, nothing else.
> But sure, we can just remove the message - at elast for now, and maybe
> add it $n releases down the road when people are expected to have
> changed over.

I'm with Robert on this one --- the first reaction I had to your
description of the patch was "why do we need a log message for that?"
If there were some real reason to push people away from use of the
non-preferred term, maybe it'd be worth nagging them to change; but
there isn't.

regards, tom lane

On Mon, Mar 14, 2011 at 16:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Mon, Mar 14, 2011 at 14:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Also, the text is not accurate: nothing has been automatically changed
>>> to anything.  The pg_hba.conf file is just as it was.  You could say
>>> something like "ident" authentication on local socket treated as
>>> "peer", but I think a better idea would be to just remove this message
>>> altogether.
>
>> The idea being to let people know it's been deprecated, nothing else.
>> But sure, we can just remove the message - at elast for now, and maybe
>> add it $n releases down the road when people are expected to have
>> changed over.
>
> I'm with Robert on this one --- the first reaction I had to your
> description of the patch was "why do we need a log message for that?"
> If there were some real reason to push people away from use of the
> non-preferred term, maybe it'd be worth nagging them to change; but
> there isn't.

Ok. fair enough, I'll take that part out.

Are people in general in favor of making the change provided I do that, then?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Mon, Mar 14, 2011 at 16:26, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Mar 14, 2011 at 16:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> On Mon, Mar 14, 2011 at 14:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> Also, the text is not accurate: nothing has been automatically changed
>>>> to anything.  The pg_hba.conf file is just as it was.  You could say
>>>> something like "ident" authentication on local socket treated as
>>>> "peer", but I think a better idea would be to just remove this message
>>>> altogether.
>>
>>> The idea being to let people know it's been deprecated, nothing else.
>>> But sure, we can just remove the message - at elast for now, and maybe
>>> add it $n releases down the road when people are expected to have
>>> changed over.
>>
>> I'm with Robert on this one --- the first reaction I had to your
>> description of the patch was "why do we need a log message for that?"
>> If there were some real reason to push people away from use of the
>> non-preferred term, maybe it'd be worth nagging them to change; but
>> there isn't.
>
> Ok. fair enough, I'll take that part out.

Here's an updated patch that removes this log message, and adds a few
lines to initdb to create a combination of ident/peer rows. And
finally, adds docs.

> Are people in general in favor of making the change provided I do that, then?

Comments?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Here's an updated patch that removes this log message, and adds a few
> lines to initdb to create a combination of ident/peer rows. And
> finally, adds docs.

> Comments?

As near as I can tell (I hate reading u-style diffs) you've documented
the ident and peer keywords as being mutually exclusive, ie, the docs
say that the correct keyword for the connection type *must* be used in
pg_hba.conf. Which is not how the code behaves, and shouldn't be how
the code behaves, for backwards-compatibility reasons. The docs need
to state the truth, namely that "ident" is still allowed as a synonym
for "peer" on local connections. Otherwise people will get confused
as to why their pg_hba files still work.

The code changes look sane in a quick scan, though I didn't read them
in detail.

regards, tom lane

On Sat, Mar 19, 2011 at 16:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Here's an updated patch that removes this log message, and adds a few
>> lines to initdb to create a combination of ident/peer rows. And
>> finally, adds docs.
>
>> Comments?
>
> As near as I can tell (I hate reading u-style diffs) you've documented

Ah, apologies. I made a -c diff, found a typo, remade it as -u.. pfft.

> the ident and peer keywords as being mutually exclusive, ie, the docs
> say that the correct keyword for the connection type *must* be used in
> pg_hba.conf.  Which is not how the code behaves, and shouldn't be how
> the code behaves, for backwards-compatibility reasons.  The docs need
> to state the truth, namely that "ident" is still allowed as a synonym
> for "peer" on local connections.  Otherwise people will get confused
> as to why their pg_hba files still work.

Hmm: Good point, update attached.

> The code changes look sane in a quick scan, though I didn't read them
> in detail.

Thx.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sat, Mar 19, 2011 at 16:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... The docs need
>> to state the truth, namely that "ident" is still allowed as a synonym
>> for "peer" on local connections. Otherwise people will get confused
>> as to why their pg_hba files still work.

> Hmm: Good point, update attached.

That looks OK to me.

regards, tom lane

On Sat, Mar 19, 2011 at 17:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Sat, Mar 19, 2011 at 16:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... The docs need
>>> to state the truth, namely that "ident" is still allowed as a synonym
>>> for "peer" on local connections.  Otherwise people will get confused
>>> as to why their pg_hba files still work.
>
>> Hmm: Good point, update attached.
>
> That looks OK to me.

Applied.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/