Re: Indent authentication overloading

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Indent authentication overloading
Date: 2011-03-10 21:22:51
Message-ID: 201103102122.p2ALMpQ11842@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-10 21:28:12 Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous Message Martijn van Oosterhout 2011-03-10 21:18:35 Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty