Re: fixing CREATEROLE
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
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: 2023-01-05T19:53:20Z
Lists: pgsql-hackers
Attachments
- v4-0001-Restrict-the-privileges-of-CREATEROLE-users.patch (application/octet-stream) patch v4-0001
- v4-0002-Add-new-GUC-createrole_self_grant.patch (application/octet-stream) patch v4-0002
On Tue, Jan 3, 2023 at 3:11 PM Robert Haas <robertmhaas@gmail.com> wrote: > Committed and back-patched 0001 with fixes for the issues that you pointed out. > > Here's a trivial rebase of the rest of the patch set. I committed 0001 and 0002 after improving the commit messages a bit. Here's the remaining two patches back. I've done a bit more polishing of these as well, specifically in terms of fleshing out the regression tests. I'd like to move forward with these soon, if nobody's too vehemently opposed to that. Previous feedback, especially from Tom but also others, was that the role-level properties the final patch was creating were not good. Now it doesn't create any new role-level properties, and in fact it has nothing to say about role-level properties in any way. That might not be the right thing. Right now, if you have CREATEROLE, you can create new roles with any combination of attributes you like, except that you cannot set the SUPERUSER, REPLICATION, or BYPASSRLS properties. While I think it makes sense that a CREATEROLE user can't hand out SUPERUSER or REPLICATION privileges, it is really not obvious to me why a CREATEROLE user shouldn't be permitted to hand out BYPASSRLS, at least if they have it themselves, and right now there's no way to allow that. On the other hand, I think that some superusers might want to restrict a CREATEROLE user's ability to hand out CREATEROLE or CREATEDB to the users they create, and right now there's no way to prohibit that. I don't have a great idea about what a system for handling this problem ought to look like. In a vacuum, I think it would be reasonable to change CREATEROLE to only allow CREATEDB, BYPASSRLS, and similar to be given to new users if the creating user possesses them, but that approach does not work for CREATEROLE, because if you didn't have that, you couldn't create any new users at all. It's also pretty weird for, say, CONNECTION LIMIT. I doubt that there's any connection between the CONNECTION LIMIT of the CREATEROLE user and the values that they ought to be able to set for users that they create. Probably you just want to allow setting CONNECTION LIMIT for downstream users, or not. Or maybe it's not even worth worrying about -- I think there might be a decent argument that limiting the ability to set CONNECTION LIMIT just isn't interesting. If someone else has a good idea what we ought to do about this part of the problem, I'd be interested to hear it. Absent such a good idea -- or if that good idea is more work to implement that can be done in the near term -- I think it would be OK to ship as much as I've done here and revisit the topic at some later point when we've had a chance to absorb user feedback. Thanks, -- 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