Re: SUBSCRIPTIONS and pg_upgrade

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SUBSCRIPTIONS and pg_upgrade
Date: 2017-04-11 13:53:55
Message-ID: CA+TgmoYa6TDgYtQStd5NnshHY0BMd=0kcMZbjATrJJs927DKDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 10, 2017 at 10:08 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Generally speaking, we should be trying to move away from superuser-only
> anything, not introducing more of it.

I totally agree, which is why I was rather surprised when you
vigorously objected to my attempts to replace the remainder of the
main tree's superuser checks that completely block execution of
certain SQL functions with privilege grants. The parameters within
which you find explicit superuser checks tolerable are extremely murky
to me.

> If the connection string can have
> sensitive data in it, ...

I would argue that a great deal of what's in a connection string could
potentially be sensitive. Do you want to disclose to unprivileged
users potentially-useful host names, IP addresses, port numbers, user
names, passwords, and/or required SSL settings? I don't think we
should assume any of that stuff to be generally OK to disclose to
non-superusers. It could be OK to disclose to everyone in some
installations, or to some people even in highly secure installations,
but the idea that there is nobody who cares about obscuring the
majority of what goes into a connection string doesn't sound right to
me.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-11 13:56:00 Re: PostGIS Out-DB Raster Not Behaving As Expected
Previous Message Tom Lane 2017-04-11 13:53:21 Re: Reversed sync check in pg_receivewal