* Bruce Momjian <bruce@momjian.us> [080104 13:00]:
> > Actually, if you just commit that patch *without* pg_hba modifications,
> > it still solves the problem stated, no? Because the client can be
> > configured to require ssl and to require server certificate validation,
> > and that's the hole we're trying to plug here...
>
> Yes, it would plug the hole without fully implementing SSL control on
> local sockets. However, the hole is already plugged by using directory
> permissions so I question the need for a partial solution at this point
> in 8.3.
Yet we have respected people warning us that the *only* place we can
have the socket is /tmp, because that's where everybody (for varying
definitions of everybody) looks. Moving the socket from /tmp actually
makes the problem of a spoofed postmaster bigger.
If you have a scheme to "move" or protect the unix socket, make sure you
still provide the one in /tmp. A simple test looks like the
/tmp/.s.PGSQL.XXXX can be a symlink the socket in the protected dir, so
it may be enough for concerned admins to create this symlink (or the
actual socket with correct owner/permissions) on system startup,
preventing an "outsider" from taking this file before postgresql (and
make sure that no tmpwatch or anything removes it again).
But if PostgreSQL is started before your "untrusted user processes",
then your untrusted user processes should never get the chance to spoof
the server unless they get to mv/delete the postgres-user owned socket
in /tmp, in which case, you've got larger problems to worry about...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.