Re: SUBSCRIPTIONS and pg_upgrade

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> 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.

Filesystem-level access seems reasonable to restrict to superusers.

> > 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.

I specifically made a point to not question what was or wasn't
considered sensitive as it can certainly vary. The point I was making
is that if there's sensitive information there then we can exclude just
that information but allow a pg_dump-using user to see that a
subscription exists without it.

I agree that it might be interesting to discuss which information should
be limited to superusers only, which information should be available to
privileged non-superusers (pg_read_all_settings, for example, allows
visibility to information that we previously limited to superusers) and
what information should be available to the 'public' user, but this
isn't the place to discuss any of that- this is about how to address the
issues which currently exist around pg_dump'ing of subscriptions (and,
perhaps, publications and they're related). I don't believe we want to
de-rail this into a largely independent discussion, given that it's an
open item that needs to be addressed shortly if we're going to get beta
out on time.

Thanks!

Stephen