All,
* Stephen Frost (sfrost@snowman.net) wrote:
> In particular, the pg_logical_* functions have superuser checks and
> those checks also allow roles who have the replication role attribute.
> That isn't something we can represent with the GRANT system currently.
I chatted with Andres a bit at PGConf.NY regarding the pg_logical_* and
the REPLICATION role attribute in general.
This is all 9.7 material, of course, but I wanted to jot down my
recollection of the discussion before it goes out of mind.
The idea we came up with is to have a pg_replication default role which
essentially replaces the REPLICATION role attribute. Andres didn't see
it as being terribly valuable to disallow a role with the REPLICATION
attribute from logging into the database directly, if it's allowed to do
so by pg_hba.conf. If the administrator doesn't wish to allow that,
then they can configure pg_hba.conf to not allow it. Further, with the
permissions handled by the GRANT system, the administrator could have
independent roles for connecting to the replication protocol and for
running the pg_logical_* functions, again, if they wish to configure
their system that way.
Lastly, Andres felt that we could keep the syntax for
setting/unsetting the role attribute and just convert those into
GRANT/REVOKE statements for the pg_replication role. I'm not thrilled
with that idea as it feels a bit unnecessary at this point, given the
relatively few users of pg_logical_* functions by tools and because it
would introduce a one-off hack in tools such as pgAdmin, which would
have to query pg_auth_members to get the current setting of the
REPLICATION role attribute, even if the code for granting/revoking that
role attribute doesn't change, unless we also hack up the views and
tables which contain role attributes today to reflect membership in
pg_replication as having (or not) that role attribute. Basically, for
my 2c, it seems like an awful lot of extra code on the backend side for
relatively small gain. pgAdmin and similar tools are going to want to
provide support for default roles in any case, along with their role
attributes support, and it doesn't seem useful to try and conflate the
two.
Andres, please correct me if any of the above is incorrect.
Thoughts and comments are welcome, of course.
Thanks!
Stephen
