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

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Noah Misch (noah@leadboat.com) wrote:
> >> > Updated patch attached.  I'll give it another good look and then commit
> >> > it, barring objections.
> >>
> >> This thread and its satellite[1] have worked their way through a few designs.
> >> At first, it was adding role attributes, alongside existing attributes like
> >> REPLICATION and BYPASSRLS.  It switched[2] to making pg_dump preserve ACLs on
> >> system objects.  Built-in roles joined[3] the pg_dump work to offer predefined
> >> collections of ACL grants.  Finally, it dropped[4] the pg_dump side and
> >> hard-coded the roles into the features they govern.
> >
> > Correct, after quite a bit of discussion and the conclusion that, while
> > pg_dump support for dumping ACLs might be interesting, it was quite a
> > bit more complex an approach than this use-case justified.
>
> Hmm.  I don't think I agree with that conclusion.  Who were the
> participants in that discussion, and how many people spoke in favor
> from moving on from that proposal - which I rather liked - to what
> you've got now?  Do you have links to the relevant portion of the
> relevant thread?

I'm not sure it's entirely relevant now- I've outlined the reasoning in
my email to Noah as a, hopefully, pretty comprehensive summary.  If that
doesn't sway your minds then it seems unlikely that a reference to a
thread from 6 months or a year ago would.  Further, as happens, other
discussions were in person where I discussed the ideas with other
hackers at conferences.  I got generally positive responses to the idea
of default roles with specific sets of rights, which is the path that
I've been on since.  As with most decisions, there was not a formal vote
over the proposals for me to reference.  I do specifically recall the
opinion that sets of privileges probably make more sense than granting
out individual ones, from Tom, if I'm remembering correctly.

In any case, I can work on the pg_dump support for catalog ACLs if there
is agreement now on that being the direction to go in.  If there's
agreement that we are happy with the idea of default roles also then I
can strip out those few which are only one-permission and which
therefore wouldn't be necessary, if we had ACL support on catalog
objects, quite easily.

> I think it's not a very good thing if we add roles that allow, say,
> execution of exactly one SQL function.  The
> dump-grants-on-system-objects proposal would accomplish the same thing
> in a much more flexible way, and with less catalog clutter.

For my 2c, I don't see a default role or two as creating terribly much
clutter.  Changing all of our code that currently has internal checks to
rely on the external checks and adjusting the permissions on the
individual functions will be a fair bit of churn though.

> More
> broadly, I'm not very convinced that even the roles which allow for
> rights on multiple objects are going to meet with general approval.

There's been rather little oposition to the idea and support when I've
discussed it.  Of course, that was before it got to the point where I
was planning to commit it.  Perhaps there will be once it's actually in,
or maybe not until it's in the wild.  In any case, I continue to feel,
as others have, that we can make adjustments moving forward.

> There has been enough discussion of which roles should be created and
> which things should be included in each one, and the overall tenor of
> that discussion seems to be that different people have different
> ideas.

Michael had a question about pg_switch_xlog, but he appeared to
reconsider that position after the subsequent discussion, which put us
back to essentially the same proposal that I started with, I believe.  I
don't recall terribly much other discussion or concern about what roles
should be created or what should be included in each one, though I'd be
happy to hear your thoughts on what you'd like to see.

I certainly don't like the idea of punting on all of this to the user to
figure out, even if it does meet the specific requirements our clients
have asked for, it strikes me that we can do better.

Thanks!

Stephen