Re: pg_upgrade using appname to lock out other users

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
> >> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >>> Peter Eisentraut wrote:
> >>>> On non-Windows servers you could get this even safer by disabling the
> >>>> TCP/IP socket altogether, and placing the Unix-domain socket in a
> >>>> private temporary directory. The "port" wouldn't actually matter then.
>
> >>> Yes, it would be nice to just create the socket in the current
> >>> directory. The fact it doesn't work on Windows would cause our docs to
> >>> have to differ for Windows, which seems unfortunate.
>
> >> It still wouldn't be bulletproof against someone running as the postgres
> >> user, so probably not worth the trouble.
>
> > But the postgres user would normally be the DBA itself, so it'd be his
> > own fault. I don't see how you can easily make any process safe from
> > interference by the same user account.
>
> Well, the point here is that it's not bulletproof, it's just making it
> incrementally harder to connect accidentally. Given that Windows
> wouldn't be covered, I don't see that it's worth the trouble compared to
> just switching to a nondefault port number. (Am I wrong to think that
> Windows users are more likely to mess up here?)

Windows is not covered if we shut off TCP and just use unix domain
sockets --- that is the only Windows-specific part I know. Windows does
work with the non-default port, and with writing the password to a file.

(FYI, I think we would need to use PGPASSWORD for the password file
option, and we don't recommend PGPASSWORD use in our docs.)

PG 9.1 already has code to lock out non-super users, but only for 9.1+
servers --- writing a password to a file would have the same only 9.2+
restriction. Non-default port numbers would work for all PG versions
because that is tied to the pg_upgrade binary.

Again, everything is easy to do --- we just have to decide. I hoped my
listing 5 items would unleash a flood of votes --- no such luck.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +