I wrote:
> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
>> On 12/11/2018 20:00, Tom Lane wrote:
>>> Also, even if we had an arguably-better idea, I suspect that there would
>>> always be cases where it didn't work. For example, one idea is to make
>>> a temporary directory under the installation's normal socket directory
>>> (thus, /tmp/pgXXXX/ or some such). But, if the normal socket directory
>>> is not /tmp, we might find that pg_upgrade can't write there.
>> We do exactly that in pg_regress and it's never been a problem.
> Yeah, but pg_upgrade is used by a much wider variety of people
> than pg_regress.
Further point about that: pg_regress's method of creating a temp
directory under /tmp is secure only on machines with the stickybit
set on /tmp; otherwise it's possible for an attacker to rename the
temp dir out of the way and inject his own socket. We agreed that
that was an okay risk to take for testing purposes, but I'm much
less willing to assume that it's okay for production use with
pg_upgrade. So I think we should keep the default situation being
that we put the socket in cwd, which we're already assuming is
secure because that's where we put the transient dump files.
That implies that we need this switch for use-cases where cwd
isn't workable due to long pathname or permissions considerations.
regards, tom lane
