On Mon, Apr 08, 2019 at 04:39:03PM +0900, Michael Paquier wrote:
> Problem is origically from 25fff40, and got worse as of 0c8910a0. A
> superuser is able to get the list of parameters, but I can easily see
> the failure when using a plain replication user. A replication user
> is one which can take a full base backup, so he can easily retrieve
> the full list of parameters anyway. What about bypassing the problem
> and just allow WAL sender contexts to always have access to parameter
> values? I don't think that this is much a security issue if one
> thinks about the access to BASE_BACKUP.
After pondering more about this one, allowing replication to have the
same rights as a superuser in this case does not feel completely right
either as this is just a shortcut to bypass the syscache lookups
happening through is_member_of_role(). So attached is a much better
and simple idea: let's just use a transaction context when issuing the
SHOW command so as it is possible to perform cache lookups correctly.
This way, even a replication role is not able to see some parameters
except if the role is a member of pg_read_all_settings, which is more
consistent.
This needs a backpatch down to v10.
Any objections to that?
--
Michael