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