Re: SUBSCRIPTIONS and pg_upgrade

On Tue, Apr 11, 2017 at 10:13 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> 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.

I think in an ideal world we wouldn't have any hard-coded superuser()
checks at all, because all privileges would be able to be delegated in
a fine-grained manner. But even if I were to agree with you on this
point, you've argued for a fairly inconsistent application of that
principle. However, I do agree with your remarks later in the email
that it's best not to derail this thread to discuss that issue in
depth, so I'll shut up about this for now.

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

OK, apparently I misread your remarks. I thought you were arguing
that the data wasn't sensitive, which seemed like an odd take.

I don't think it's the purpose of pg_dump to reveal what objects
exist, but rather to create a dump file that can be used to recreate
the state of the database. To the extent that the user lacks
permissions necessary to dump the objects, they can't be dumped.
Maybe modifying subscriptions so that they can exist without a
connection and "half-dumping" them is better than not dumping them at
all, but my initial impression is to think that it's worse. A user
may be more likely to notice something that's missing altogether than
something that exists but in a non-working state. You mentioned
--no-role-passwords, but that's a nasty kludge in my book and I'm not
in favor of making something like that the default behavior. Peter's
approach looks like less work, and helps us get beta out the door.

I can't claim to be an expert on all of this, though.

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