* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost <sfr...@snowman.net> wrote: > > * Noah Misch (n...@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
signature.asc
Description: Digital signature
