Re: Additional role attributes && superuser review

On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> * Noah Misch (noah(at)leadboat(dot)com) wrote:

> The one argument which you've put forth for adding the complexity of
> dumping catalog ACLs is that we might reduce the number of default
> roles provided to the user.

Right. If "GRANT EXECUTE ON FUNCTION pg_rotate_logfile() TO mydba" worked as
well as it works on user-defined functions, the community would not choose to
add a pg_rotate_logfile role holding just that one permission.

> I disagree that we would. Having a single
> set of default roles which provide a sensible breakdown of permissions
> is a better approach than asking every administrator and application
> developer who is building tools on top of PG to try and work through
> what makes sense themselves, even if that means we have a default role
> with a small, or even only an individual, capability.

The proposed pg_replication role introduces abstraction that could, as you
hope, spare a DBA from studying sets of functions to grant together. The
pg_rotate_logfile role, however, does not shield the DBA from complexity.
Being narrowly tied to a specific function, it's just a suboptimal spelling of
GRANT. The gap in GRANT has distorted the design for these predefined roles.
I do not anticipate a sound design discussion about specific predefined roles
so long as the state of GRANT clouds the matter.

> > To summarize, I think the right next step is to resume designing pg_dump
> > support for system object ACLs. I looked over your other two patches and will
> > unshelve those reviews when their time comes.
>
> To be clear, I don't believe the two patches are particularly involved
> with each other and don't feel that one needs to wait for the other.

Patch 2/3 could stand without patch 3/3, but not vice-versa. It's patch 2/3
that makes pg_dumpall skip ^pg_ roles, and that must be in place no later than
the first patch that adds a predefined ^pg_ role.

> Further, I'm not convinced that adding support for dumping ACLs or, in
> general, encouraging users to define their own ACLs on catalog objects
> is a good idea. We certainly have no mechanism in place today for those
> ACLs to be respected by SysCache and encouraging their use when we won't
> actually respect them is likely to be confusing.

What's this problem with syscache? It sounds important.

nm