Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> 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.)
A server has *always* presented its certificate. SSL doesn't work otherwise. What we can't know is if the client *verified* the certificate. But there's no way to control that from server-side anyway... And we do request the client certificate if the server is provided with a root certificate store to verify it against... I'm not sure we gain a lot by adding a second option to do the same thing (which still will need said root certificate store to work) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org