Skip site navigation (1) Skip section navigation (2)

Re: Spoofing as the postmaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spoofing as the postmaster
Date: 2007-12-27 21:46:01
Message-ID: 20883.1198791961@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I have no problem with that. But it does seem to me that we are going 
> about this all wrong. The OP proposed a "solution" which was intended to 
> ensure at the server end that an untrusted user could not spoof the 
> postmaster if the postmaster were not running. Putting the onus of this 
> on clients seems wrong. I don't have any experience with SELinux, but my 
> impression is that it can be used to control who or what can open files, 
> sockets etc. On Linux at least this strikes me as a more productive 
> approach to the original problem, as it would put the solution in the 
> SA's hands. Maybe other Unices and Windows have similar capabilities?

Most Linux distros don't have SELinux, AFAIK, so this is probably not a
very useful suggestion.  Not that I have a problem with Red-Hat-specific
solutions ;-) ... but since one of the arguments being made against
move-the-socket is that it introduces a lot of platform-specific
assumptions, we have to apply that same criterion to alternative
answers.

As far as ensuring security from the server end, what about extending
the pg_hba.conf options to require that the server has both checked
a client certificate and presented its own certificate?  (I'm not sure
whether OpenSSL provides a way to determine that, though.)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2007-12-27 21:50:22
Subject: Re: Spoofing as the postmaster
Previous:From: Simon RiggsDate: 2007-12-27 21:29:11
Subject: Re: Archiver behavior at shutdown

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group