Re: pg_upgrade using appname to lock out other users

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +