Re: pg_upgrade using appname to lock out other users

On Thu, Jun 16, 2011 at 5:16 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> > I now believe we are overthinking all this. ?pg_upgrade has always
>> > supported specification of a port number. ?Why not just tell users to
>> > specify an unused port number > 1023, and not to use the default value?
>>
>> 1. Because it shouldn't be the user's problem to figure out a good
>> choice of port number.
>>
>> 2. Because we also really ought to be ignoring the contents of
>> pg_hba.conf during an upgrade, and instead have some mechanism that
>> allows pg_upgrade to be sure of getting in (without creating a
>> security hole in the process).
>>
>> I agree that back-patching these changes wouldn't be a wonderful
>> thing, but we are going to do a lot more releases that have pg_upgrade
>> in them in the future than we've already done in the past.  It's not a
>> bad thing to try to start improving on the basic mechanism, even if
>> takes a while for versions that support that mechanism to become
>> commonplace.  Limiting what we're willing to do the server to improve
>> the pg_upgrade experience in the future to what we're willing to
>> back-patch is not going to be a winning strategy.
>
> OK, well, we have three possible directions:
>
> 1.  Just document that people should use -p and -P on unused ports to
> avoid user connections
>
> 2.  Do #1 and also require -p and -P to be used (no defaults)
>
> 3.  Have pg_upgrade default to use a typically unused port number, e.g.
> 25432 (on Unix, it might only be using unix domain sockets anyway)
>
> 4.  Require appname to match 'binary-upgrade' when in -b (binary-upgrade)
> mode
>
> 5.  Disable TCP when in -b mode on Unix (not possible on Windows)
>
> We can pick different options for 9.0, 9.1, and 9.2.  (For PG 9.0
> probably only #1 is appropriate.)

I don't like any of these options as well as what I already proposed.
I proposed a complicated approach that actually fixes the problem for
real; you're proposing a whole bunch of simpler approaches all of
which have pretty obvious holes.  We already have something that only
sorta works; replacing it with a different system that only sorta
works is not going to be a great leap forward.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company