Re: Additional role attributes && superuser review

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> 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.

I've found consensus among folks on the lists for far more of my commits
than I've cited off-list discussions for. Further, consensus on these
lists is largely in the quiet, which is why I go out of my way to
attempt to engage parties who may be interested when there *isn't* much
discussion on the lists. I'm trying to do better than simply assuming
consensus based on no feedback to the contrary. Had I assumed minimal
response meant consensus for this patch, as is typically the norm, this
patch would have been committed six months ago. Instead, I tried to
engage people at conferences to ensure that there really was consensus
on the approach.

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

The 'role or two' was under the expectation that we'd still have default
roles for the more complicated cases (pg_backup, et al) and that we
would only be removing the default role of pg_switch_xlog and
pg_file_settings (the only two which an individual GRANT could replace).

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

I implemented the discussed pg_dump support for ACLs and looked at the
changes required. I may not be remembering it entirely, but it's not
that I've not looked at 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.

I agree that this has largely been the on-list reaction. To be fair,
it's been largely the off-list reaction also, which I've expressly
tried to seek out, as mentioned above. I'm not asking anyone to love
it, I'm not entirely convinced it's lovable myself, but I do feel it's
useful and worth making an effort for.

> >> 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'd love to have folks from other companies involved in these
discussions. I'll even reach out explicitly to seek their comment, as
I've done with other hackers at conferences, and try to get them to
voice their opinions here.

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

If it didn't come with the other baggage that I've tried to explain, I'd
agree that having pg_dump support ACLs on catalog objects to be a
sensible and good thing, even if I might still argue that default roles
are better.

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

For my 2c, I believe that to be, by-and-large, because they don't want
to get their hopes up until they see something actually get committed.
Following long and deep threads such as these are quite a committment.

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

We *have* heard complaints from people, multiple times on various lists,
that they'd like to set up check_postgres, Nagios, $MONITORINGTOOL, with
a role that *isn't* a superuser. I'll ask Greg S-M if he would have
time to weigh in on this though, check_postgres was specifically one of
the tools which I was looking at when considering the pg_monitor role.

I'm not sure about the references you use above to Slony or pgBouncer or
pgPool as those aren't backup tools, to my mind.. I would expect barman
and other backup tools to also use pg_start/stop_backup and
pg_switch_xlog. I'm not sure that there's a way to cater to one backup
role when it comes to how filesystem-level backups are handled in PG,
but perhaps I've missed something there that barman uses and which isn't
included currently.

Of course, my reviewing barman or other tools wouldn't have the same
support as Simon weighing in, so I'll try and pursue that avenue as
well.

Thanks!

Stephen