Re: fixing CREATEROLE
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, walther@technowledgy.de, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-11-28T21:55:04Z
Lists: pgsql-hackers
On Mon, Nov 28, 2022 at 4:19 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > That's fine, but are you saying this patch is incapable (or simply undesirable) of having the parts about handling defaults separated out from the parts that define how the system works with a given set of permissions; and the one implementation detail of having the bootstrap superuser automatically grant admin to any roles a createuser role creates? If you and others feel strongly about defaults I'm sure that the suggested other thread focused on that will get attention and be committed in a timely manner. But the system will work, and not be broken, if that got stalled, and it could be added in later. The topics are so closely intertwined that I don't believe that trying to have separate discussions will be useful or productive. There's no hope of anybody understanding 0004 or having an educated opinion about it without first understanding the earlier patches, and there's no requirement that someone has to review 0004, or like it, just because they review or like 0001-0003. But so far nobody has actually reviewed anything, and all that's happened is people have complained about 0004 for reasons which in my opinion are pretty nebulous and largely ignore the factors that caused it to exist in the first place. We had about 400 emails during the last release cycle arguing about a whole bunch of topics related to user management, and it became absolutely crystal clear in that discussion that Stephen Frost and David Steele wanted to have roles that could create other roles but not immediately be able to access their privileges. Mark and I, on the other hand, wanted to have roles that could create other roles WITH immediate access to their privileges. That argument was probably the main thing that derailed that entire patch set, which represented months of work by Mark. Now, I have come up with a competing patch set that for the price of 100 lines of code and a couple of slightly ugly option names can do either thing. So Stephen and David and any like-minded users can have what they want, and Mark and I and any like-minded users can have what we want. And the result is that I've got like five people, some of whom particulated in those discussions, showing up to say "hey, we don't need the ability to set defaults." Well, if that's the case, then why did we have hundreds and hundreds of emails within the last 12 months arguing about which way it should work? -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Add new GUC createrole_self_grant.
- e5b8a4c098ad 16.0 landed
-
Restrict the privileges of CREATEROLE users.
- cf5eb37c5ee0 16.0 landed
-
Pass down current user ID to AddRoleMems and DelRoleMems.
- 39cffe95f2c5 16.0 landed
-
Refactor permissions-checking for role grants.
- 25bb03166b16 16.0 landed
-
Improve documentation of the CREATEROLE attibute.
- 0b496bc9881f 11.19 landed
- 1a5ff7be2696 12.14 landed
- 5dac191edf18 13.10 landed
- 1c77873727df 16.0 landed
- 5136c3fb575b 14.7 landed
- aa26980ca081 15.2 landed
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 cited