Re: CREATEROLE and role ownership hierarchies
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Joshua Brindle <joshua.brindle@crunchydata.com>,
Andrew Dunstan <andrew@dunslane.net>, Shinya Kato <Shinya11.Kato@oss.nttdata.com>, "Bossart,
Nathan" <bossartn@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Jeff Davis <pgsql@j-davis.com>
Date: 2022-01-24T20:33:01Z
Lists: pgsql-hackers
On Sat, Jan 22, 2022 at 4:20 PM Stephen Frost <sfrost@snowman.net> wrote: > Whoah, really? No, I don't agree with this, it's throwing away the > entire concept around inheritance of role rights and how you can have > roles which you can get the privileges of by doing a SET ROLE to them > but you don't automatically have those rights. I see it differently. In my opinion, what that does is make the patch actually useful instead of largely a waste of time. If you are a service provider, you want to give your customers a super-user-like experience without actually making them superuser. You don't want to actually make them superuser, because then they could do things like change archive_command or install plperlu and shell out to the OS account, which you don't want. But you do want them to be able to administer objects within the database just as a superuser could. And a superuser has privileges over objects they own and objects belonging to other users automatically, without needing to SET ROLE. Imagine what happens if we adopt your proposal here. Everybody now has to understand the behavior of a regular account, the behavior of a superuser account, and the behavior of this third type of account which is sort of like a superuser but requires a lot more SET ROLE commands. And also every tool. So for example pg_dump and restore isn't going to work, not even on the set of objects this elevated-privilege user can access. pgAdmin isn't going to understand that it needs to insert a bunch of extra SET ROLE commands to administer objects. Ditto literally every other tool anyone has ever written to administer PostgreSQL. And for all of that pain, we get exactly zero extra security. -- Robert Haas EDB: http://www.enterprisedb.com
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