Andrew Dunstan wrote:
> D'Arcy J.M. Cain wrote:
>> - 1: How does the client assure that the postmaster is legit
>> - 2: How does the postmaster assure that the client is legit
> And neither answers the original problem:
> 3. How can the sysadmin prevent a malicious local user from hijacking
> the sockets if the postmaster isn't running?
> Prevention is much more valuable than ex post detection, IMNSHO.
> Probably the first answer is not to run postgres on a machine with
> untrusted users, but that's not always possible. Maybe we can't find a
> simple cross-platform answer, but that doesn't mean we should not look
> at platform-specific answers, at least for documentation.
I thought this answer was already provided: Put the socket in a
directory that is only writable by the database owner. The socket is
created as part of the bind() process. I think this covers 90%+ of it,
and is already in use by distributions. The only thing "better" this
team could do would be to formalize it? The "serveruser=" db open
parameter might be enough to lock it up tight if there is still a race
condition on bind(). It's effectively a very cheap authentication
mechanism that does not require expensive cryptographic operations.
There is probably value to making SSL consistent for TCP/UNIX sockets as
Tom suggests. Removing the inconsistency as it were, and allowing for
SSL authentication and encryption for UNIX sockets the same as for TCP
sockets. If it was as simple as removing an if statement that would be
even cooler... :-)
What has come out for me is that this isn't UNIX socket specific at all
(although there may be UNIX socket specific options available). The
standard PostgreSQL port is above 1024, and anybody could
bind()/listen()/accept() on it, assuming it is not running. This is
where your first answer of running PostgreSQL on a machine with trusted
users comes in as a sensible recommendation, even if only some people
are willing to accept this recommendation. :-)
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
