Re: Additional role attributes && superuser review

On Mon, Jan 4, 2016 at 3:07 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> 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.

To be honest, that's not really my point. You have cited off-list
discussions you've had over and over as a reason why you proceeded
down some particular path. That is fine up to a point - I discuss
lots of things with people off-list, too - but a consensus that a
particular design is acceptable for commit has to mean the consensus
on this mailing list, and nothing else. In seven years of reading
this mailing list, I can't remember a single other person on this
mailing list saying "I'm going to commit this because I talked to a
bunch of unspecified people at conferences I attended and they liked
it", but you've used essentially that rationale a couple of times now.

> For my 2c, I don't see a default role or two as creating terribly much
> clutter.

I don't believe any version of this proposal has involved only one or
two such roles. They've all had at least four or five AFAICS. Now
maybe that's still OK, but 4 or 5 > 1 or 2, and the number is only
likely to go up in the future.

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

I'm not sure it'll really be that bad, but if you have some evidence
that I'm wrong I'd like to hear it.

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

So, is this another case where the support is all in off-list fora and
thus invisible, or can you point to specific on-list discussions where
it was supported, and to the opinions offered in support? I don't
really remember many opinions that were any more positive than "I
wouldn't be strongly opposed to this" or "If we're going to do this
then we ought to do it in X way". I'm happy to be corrected if I'm
misrepresenting the record, but I'd characterize the overall reaction
to this proposal as tepid: nobody hated it, but nobody really loved it
either, and a bunch of mild concerns were offered.

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

Honestly, my vote is for creating only those predefined roles that are
clearly endorsed by three people with different employers, which I
currently believe to be true of none of the proposed roles. It's not
even that I suspect you or anyone of ballot-stuffing; it's just that
people who work at different companies are likely to work with
different tools and those tools may have different requirements. I
mean, people at 2ndQuadrant probably mostly use repmgr; people at
Crunchy probably like pgbackrest; people at OmniTI probably use
PITRtools; and EnterpriseDB employees are more likely than average to
be familiar with BART. If several of those people come together and
say they all agree that predefined role X is perfect for the needs of
all of their respective tools, I'd consider that a really good sign
that we've hit on something that is of general utility. Otherwise,
I'd just the authors of each tool specify the GRANT EXECUTE ON
FUNCTION lines necessary for their own tool and call it good. I think
that's almost as convenient and a lot more flexible.

What really bothers me about this thread is that these predefined
roles are intended to be useful for third-party tools, but the people
who maintain those third-party tools have said basically nothing. I
don't recall, for example, Dave Page weighing in on what pgAdmin
needs, or anybody commenting on to what degree any of these proposals
would meet the needs of Slony or pgBouncer or pgPool or any backup
tool (other than perhaps pgbackrest, which I assume your proposals
cater to) or any monitoring tool. Like, we've heard zip. Either
those people don't know this thread exists, or they can't understand
it, or they think it's so boring that they can't be bothered to write
in and say whether this is useful or not. I'd have a lot more
confidence that we are making a good decision if some of those people
would show up and say "I have reviewed this proposal and it looks {
great | terrible | mediocre } for $TOOL because $REASON".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company