Re: postgres ident error
On Tue, 2004-05-25 at 02:36, Tom Allison wrote:
> So the "tcpip_socket=yes" statement has nothing to do with TCP/IP
> connection? While tcpip_sockets=no is the default from postgres, the
> configuration file in Debian shows otherwise.
tcpip_socket=yes makes the postmaster listen for TCP/IP connections.
However, that says nothing about authentication.
If you connect with host=localhost, it uses a TCP/IP socket to
localhost. If you connect with host='' it uses a Unix socket.
TCP/IP connections that use ident authentication query the remote ident
server; Unix sockets with ident authentication use the peer credentials
of the socket (which ultimately derive from /etc/passwd on the local
machine).
> However, it is not accessible from any other network address (sockets
> and localhost only).
By default, we allow Unix socket connections (which by definition come
from the local machine) and TCP/IP connections to localhost (since we
assume that a locally-installed ident server can be trusted). Any other
connection sources must be authorised by editing pg_hba.conf.
...
> All of this that you say here regarding the access of IDENT servers
> versus ident-ish calls to /etc/passwd is probably true (I don't have
> enough information on the specifics to doubt you). As it appears in the
> configuration files, both sockets and tcp/ip (localhost only) are
> enabled, so it could be either one or both. All of which still denies
> network access.
>
>
> However, from postgres' own documentation, they clearly warn against the
> use of IDENT servers as a means of authentication when accessing the
> database over anything other than sockets or possibly localhost.
>
> This kind of falls under the category of Monty Pythons the Chocolate
> shop skit where you have the warning: "Danger: real live unboned crunchy
> dead frog"
Sorry, that's the way it is. I assume we can trust a local ident server
because I assume it is a Debian package and that the local administrator
is trustworthy; in any case, he is the one installing the postgresql
package, so I have no choice but to trust him.
In the case of any other machine, I have no idea whether it is
trustworthy or not. Even if it appears to be on the same network, I
don't know its physical location. It might even be a Windows machine,
and I'd be insane to trust that! So the pg_hba.conf file as distributed
does not allow access from any remote machine; the administrator has to
work out for himself what machines he can trust and how to verify
connections from them.
> I fully understand that postgresql as configured is pretty much secure,
> but the implication that this method of authentication can be applied to
> non-localhost network connections might do better to carry a warning in
> the configuration somewhere, even a README.Debian would be at least
> something. It would be very easy for someone to just copy/paste/edit
> and end up with a problem.
I should have thought that the fact that access is locked down to the
local machine would give him to think a bit and wonder why! I can't
summon up much sympathy for people who randomly open their security
without thinking about it, but you're welcome to submit a bug report
with a proposed patch.
--
Oliver Elphick olly@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"And Jesus answering said unto them, They that are
whole need not a physician; but they that are sick. I
come not to call the righteous, but sinners to
repentance." Luke 5:31,32
Reply to: