Re: Additional role attributes && superuser review

On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
>> * Noah Misch (noah(at)leadboat(dot)com) wrote:
>> 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.

As the patch stands, the system roles that are just close to synonyms
of GRANT/REVOKE are the following:
- pg_file_settings, which works just on the system view
pg_file_settings and the function pg_show_all_file_settings().
- pg_rotate_logfile as mentioned already.
- pg_signal_backend, which is just checked once in pg_signal_backend
Based on those concerns, it looks clear that they should be shaved off
from the patch.

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

I am a bit confused by this statement, and I disagree with Stephen's
point as well. It seems to me that 2/3 exists *because* 3/3 is here.
Why would we want to restrict the role names that can be used if we
are not going to introduce some system roles that are created at
bootstrap?
--
Michael