Re: Additional role attributes && superuser review - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Additional role attributes && superuser review
Date
Msg-id 20151231072615.GA2865494@tornado.leadboat.com
Whole thread Raw
In response to Re: Additional role attributes && superuser review  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Additional role attributes && superuser review
Re: Additional role attributes && superuser review
List pgsql-hackers
On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> * Noah Misch (noah@leadboat.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



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Better detail logging for password auth failures
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport