Re: [HACKERS] SSL over Unix-domain sockets - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] SSL over Unix-domain sockets
Date
Msg-id 19315.1200622602@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] SSL over Unix-domain sockets  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [HACKERS] SSL over Unix-domain sockets
List pgsql-patches
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I propose to create a dangling symlink on system startup in
> /tmp/.s.PGSQL.<port> to the real socket, which is not on a
> world-writable directory.  This avoids the spoofer, because he cannot
> create the socket -- the symlink is occupying its place.

> The only problem with this proposal is that the tmp cleaner would remove
> the symlink.  The solution to this is to configure the tmp cleaner so
> that it doesn't do that.

> It absolutely requires cooperation from the sysadmin, both to setup the
> symlink initially, and to configure the tmp cleaner.

This is definitely a slick solution if you can overcome the tmp-cleaner
risk; not least because it doesn't require any work on our part ;-).
However, we should document the approach someplace.

Further down the road we could think about Postgres changes to support
such a strategy --- for instance, having the postmaster check to see
if such a link exists.  This will require more thought than we have
time for for 8.3; also I think we'd need to negotiate with packagers,
such as the Debian crew, to make sure any such behavior is acceptable
to them.

BTW, is a symlink's atime changed by accessing it?  We could imagine
adapting the existing postmaster code that keeps the socket atime fresh
so that it will work on a symlink, thus providing partial protection
against tmp-cleaners.  Portability of this is uncertain...

            regards, tom lane

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] SSL over Unix-domain sockets
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] SSL over Unix-domain sockets