On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e@gmx.net> wrote:
> It has been discussed several times in the past that there is no way for
> a client to authenticate a server over Unix-domain sockets. So
> depending on circumstances, a local user could easily insert his own
> server and collect passwords and data. Suggestions for possible
> remedies included:
>
> You can put the socket file in a sufficiently write-protected directory.
> But that would strongly deviate from the default setup, and anyway the
> client still cannot readily verify that the server is the right one.
>
> You can also run SSL over Unix-domain sockets. This is currently
> disabled in the code, but it would work just fine. But it's obviously
> kind of awkward, and the connection overhead was noticeable in tests.
>
> Then it was suggested to use the local "ident" mechanism in reverse, so
> the client could verify what user the server runs under. I have
> implemented a prototype of this. You can put, e.g.,
>
> requirepeer=postgres
>
> into the connection parameters, and the connection will be rejected
> unless the process at the other end of the socket is running as
> postgres.
>
> The patch needs some portability work and possible refactoring because
> of that, but before I embark on that, comments on the concept?
I like it. ISTM like something that would be very useful - an easy way
to get a fair amount of extra security in the case of local
connections, at almost zero cost. Just an "export
PGREQUIREPEER=postgres" in .profile goes a long way :-)
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
