Re: CREATEROLE and role ownership hierarchies
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>,
Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan
<andrew@dunslane.net>, "Bossart, Nathan" <bossartn@amazon.com>,
Jeff Davis <pgsql@j-davis.com>,
Joshua Brindle <joshua.brindle@crunchydata.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Shinya Kato <Shinya11.Kato@oss.nttdata.com>
Date: 2022-01-25T06:55:49Z
Lists: pgsql-hackers
On 2022/01/25 8:18, Mark Dilger wrote: > > >> On Jan 24, 2022, at 2:21 PM, Stephen Frost <sfrost@snowman.net> wrote: >> >> Superuser is a problem specifically because it gives people access to do absolutely anything, both for security and safety concerns. Disallowing a way to curtail that same risk when it comes to role ownership invites exactly those same problems. > > Before the patch, users with CREATEROLE can do mischief. After the patch, users with CREATEROLE can do mischief. The difference is that the mischief that can be done after the patch is a proper subset of the mischief that can be done before the patch. (Counter-examples highly welcome.) > > Specifically, I claim that before the patch, non-superuser "bob" with CREATEROLE can interfere with *any* non-superuser. After the patch, non-superuser "bob" with CREATEROLE can interfere with *some* non-superusers; specifically, with non-superusers he created himself, or which have had ownership transferred to him. > > Restricting the scope of bob's mischief is a huge win, in my view. +1 One of "mischiefs" I'm thinking problematic is that users with CREATEROLE can give any predefined role that they don't have, to other users including themselves. For example, users with CREATEROLE can give pg_execute_server_program to themselves and run any OS commands by COPY PROGRAM. This would be an issue when providing something like PostgreSQL cloud service that wants to prevent end users from running OS commands but allow them to create/drop roles. Does the proposed patch fix also this issue? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 landed
-
Ensure that pg_auth_members.grantor is always valid.
- 6566133c5f52 16.0 landed
-
Remove the ability of a role to administer itself.
- 79de9842ab03 15.0 landed
-
Add tests of the CREATEROLE attribute
- e9d4001ec592 15.0 landed
-
Replace explicit PIN entries in pg_depend with an OID range test.
- a49d08123599 15.0 cited
-
Shore up ADMIN OPTION restrictions.
- fea164a72a7b 9.4.0 cited
-
Add pg_has_role() family of privilege inquiry functions modeled after the
- f9fd1764615e 8.1.0 cited
-
Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion
- 4b2dafcc0b1a 8.0.0 cited