Re: allowing for control over SET ROLE
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Stephen Frost <sfrost@snowman.net>, Nathan Bossart <nathandbossart@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-01-03T22:03:11Z
Lists: pgsql-hackers
On Tue, Jan 03, 2023 at 02:43:10PM -0500, Robert Haas wrote: > On Sat, Dec 31, 2022 at 1:16 AM Noah Misch <noah@leadboat.com> wrote: > > On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote: > > > On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote: > > > > But I think the bigger reason is that, in my opinion, this proposal is > > > > more generally useful, because it takes no position on why you wish to > > > > disallow SET ROLE. You can just disallow it in some cases and allow it in > > > > others, and that's fine. > > > > In this commit 3d14e17, the documentation takes the above "no position". The > > implementation does not, in that WITH SET FALSE has undocumented ability to > > block ALTER ... OWNER TO, not just SET ROLE. Leaving that undocumented feels > > weird to me, but documenting it would take the position that WITH SET FALSE is > > relevant to the security objective of preventing object creation like the > > example in the original post of this thread. How do you weigh those > > documentation trade-offs? > > In general, I favor trying to make the documentation clearer and more > complete. Intentionally leaving things undocumented doesn't seem like > the right course of action to me. For what it's worth, I like to leave many things undocumented, but not this. > That said, the pre-existing > documentation in this area is so incomplete that it's sometimes hard > to figure out where to add new information - and it made no mention of > the privileges required for ALTER .. OWNER TO. I didn't immediately > know where to add that, so did nothing. I'd start with locations where the patch already added documentation. In the absence of documentation otherwise, a reasonable person could think WITH SET controls just SET ROLE. The documentation of WITH SET is a good place to list what else you opted for it to control. If the documentation can explain the set of principles that would be used to decide whether WITH SET should govern another thing in the future, that would provide extra value.
Commits
-
More documentation update for GRANT ... WITH SET OPTION.
- 3cdf7502f85c 16.0 landed
-
Restrict the privileges of CREATEROLE users.
- cf5eb37c5ee0 16.0 cited
-
Add support for GRANT SET in psql tab completion
- 9d0cf574920f 16.0 landed
-
Add a SET option to the GRANT command.
- 3d14e171e9e2 16.0 landed
-
Allow grant-level control of role inheritance behavior.
- e3ce2de09d81 16.0 cited