Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost <sfr...@snowman.net> wrote: > > Clearly, further testing and documentation is required and I'll be > > getting to that over the next couple of days, but it's pretty darn late > > and I'm currently getting libpq undefined reference errors, probably > > because I need to set LD_LIBRARY_PATH, but I'm just too tired to now. :) > > > > Thoughts? > > The tricky part of this seems to me to be the pg_dump changes. The > new catalog flag seems a little sketchy to me; wouldn't it be better > to make the dump flag into an enum, DUMP_EVERYTHING, DUMP_ACL, > DUMP_NONE?
I agree that the pg_dump changes are a very big part of this change.
I'll look at using an enum and see if that would work.
> Is this creating a user-visible API break, where pg_stat_activity and
> pg_stat_replication now always show only the publicly-visible
> information, and privileged users must explicitly decide to query the
> _all versions? If so, -1 from me on that part of this.
Thanks for bringing it up. No, the existing API is exactly the same for
the existing views- the only difference is that now there are _all
versions which provide unfiltered data (but you have to have permission
to call the _all() functions underneath, or you get a permission denied
error).
Where this does have an API change is with the simpler functions that
used to do "if (superuser() || replication_role())" and now depend on
the GRANT system instead. We can't (today, at least) say:
GRANT EXECUTE ON function_whatever() TO replication_roles;
And have that be kept current as that role attribute is modified. I've
not done it yet, but we could certainly have pg_dump dump out GRANTs for
the *current* users which have that role attribute and give those users
access to the functions via the normal permissions system. I'm not
really sure that's a good idea though- it might be better to have a
clean break here (and one which is clearly in the "more secure/explicit"
direction) and tell admins in the release notes to GRANT EXECUTE on the
functions for the roles they want to give permission to. We could also
duplicate the functions and have the existing ones remain as-is and have
the new ones just depend on the GRANT system, but I don't particularly
like that since I'm afraid we'd end up in the same boat we're in now
with pg_user and friends.
Thanks!
Stephen
signature.asc
Description: Digital signature
