On Wed, Nov 20, 2013 at 05:38:14PM -0500, Gurjeet Singh wrote:
> On Wed, Nov 20, 2013 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> To my mind, the "create a socket and hope nobody else can get to it"
> approach is exactly one of the main things we're trying to avoid here.
> If you'll recall, awhile back we had a big discussion about how pg_upgrade
> could positively guarantee that nobody messed with the source database
> while it was working, and we still don't have a bulletproof guarantee
> there. I would like to fix that by making pg_upgrade use only standalone
> backends to talk to the source database, never starting a real postmaster
> at all. But if the standalone-pg_dump mode goes through a socket, we're
> back to square one on that concern.
>
>
> (I couldn't find the pg_upgrade-related thread mentioned above).
>
> I am not sure of the mechanics of this, but can we not launch the postmaster
> with a random magic-cookie, and use that cookie while initiating the connection
> from libpq. The postmaster will then reject any connections that don't provide
> the cookie.
>
> We do something similar to enable applications to send cancellation signals
> (postmaster.c:Backend.cancel_key), just that it's establishing trust in the
> opposite direction.
The magic cookie can be tha application_name. I had pg_upgrade code to
prevent anyone from connecting unless their application_name was
"pg_upgrade", but the idea was rejected.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
