Mark Mielke wrote:
> I prefer UNIX sockets with kernel credential passing over TCP/IP with
> username/password or the more expensive SSL. I do not like storing
> passwords or private certificates in a place available to the web user,
> as other web users would then also have access. I do not have evidence,
> but I am under the impression that the TCP/IP stack incurs additional
> overhead on connect(), send(), recv(), and close() than UNIX sockets.
I think that was one of the original reasons the Unix sockets code was
added at all.
> How expensive would it be to implement a "server_user" db open parameter
> that would perform reverse credential passing to validate? "dbname=XXX
> port=5432 server_user=postgres". If the server can't prove it is
> postgres through UNIX socket credential passing, it fails. Similarly,
Probably not very, but you should be able to achieve the same thing by
moving the socket to a protected directory, I think?
> identd may be usable in reverse? I've seen many people claim identd is
> insecure - but it is secure if I am the one running it, is it not?
AFAIK, it's secure if the host that it's running on can be considered
secure. It's not secure over the internet, because by definition
wherever the client runs is not under your control. But if you fully
control the machine that the client runs on, AFAIK, ident should be secure.
//Magnus
