On Mon, Jan 24, 2022 at 5:21 PM Stephen Frost <sfr...@snowman.net> wrote: > This is an argument to drop the role ownership concept, as I view it. > Privileges are driven by membership today and inventing some new independent > way to do that is increasing confusion, not improving things. I disagree > that adding role ownership should necessarily change how the regular GRANT > privilege system works or throw away basic concepts of that system which have > been in place for decades. Increasing the number of independent ways to > answer the question of “what users have what rights on object X” is an active > bad thing. Anything that cares about object access will now also have to > address role ownership to answer that question, while if we don’t include > this one change then they don’t need to directly have any concern for > ownership because regular object privileges still work the same way they did > before.
It really feels to me like you just keep moving the goalposts. We started out with a conversation where Mark said he'd like to be able to grant permissions on GUCs to non-superusers.[1] You argued repeatedly that we really needed to do something about CREATEROLE [2,3,4]. Mark argued that this was an unrelated problem[5] but you argued that unless it were addressed, users would still be able to break out of the sandbox[6] which must mean either the OS user, or at least PostgreSQL users other than the ones they were supposed to be able to control. That led *directly* to the patch at hand, which solves the problem by inventing the notion of role ownership, so that you can distinguish the roles you can administer from the ones you drop. You are now proposing that we get rid of that concept, a concept that was added four months ago[7] as a direct response to your previous feedback. It's completely unfair to make an argument that results in the addition of a complex piece of machinery to a body of work that was initially on an only marginally related topic and then turn around and argue, quite close to the end of the release cycle, for the removal of that exact same mechanism. And your argument about whether the privileges should be able to be exercised without SET ROLE is also just completely baffling to me given the previous conversation. It seems 100% clear from the previous discussion that we were talking about service provider environments and trying to deliver a good user experience to "lead tenants" in such environments. Regardless of the technical details of how INHERIT or anything else work, an actual superuser would not be subject to a restriction similar to the one you're talking about, so arguing that it ought to be present here for some technical reason is placing technicalities ahead of what seemed at the time to be a shared goal. There's a perfectly good argument to be made that the superuser role should not work the way it does, but it's too late to relitigate that. And I can't imagine why any service provider would find any value in a new role that requires all of the extra push-ups you're trying to impose on it. I just can't shake the feeling that you're trying to redesign this patch out of (a) getting committed and (b) solving any of the problems it intends to solve, problems with which you largely seemed to agree. I assume that is not actually your intention, but I can't think of anything you'd be doing differently here if it were. [1] https://www.postgresql.org/message-id/F9408A5A-B20B-42D2-9E7F-49CD3D1547BC%40enterprisedb.com [2] https://www.postgresql.org/message-id/20210726200542.GX20766%40tamriel.snowman.net [3] https://www.postgresql.org/message-id/20210726205433.GA20766%40tamriel.snowman.net [4] https://www.postgresql.org/message-id/20210823181351.GB17906%40tamriel.snowman.net [5] https://www.postgresql.org/message-id/92AA9A52-A644-42FE-B699-8ECAEE12E635%40enterprisedb.com [6] https://www.postgresql.org/message-id/20210823195130.GF17906%40tamriel.snowman.net [7] https://www.postgresql.org/message-id/67BB2F92-704B-415C-8D47-149327CA8F4B%40enterprisedb.com -- Robert Haas EDB: http://www.enterprisedb.com
