Re: allowing for control over SET ROLE

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Noah Misch <noah@leadboat.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-03T19:43:10Z
Lists: pgsql-hackers
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. 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. Maybe I should have tried
harder, though.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

  1. More documentation update for GRANT ... WITH SET OPTION.

  2. Restrict the privileges of CREATEROLE users.

  3. Add support for GRANT SET in psql tab completion

  4. Add a SET option to the GRANT command.

  5. Allow grant-level control of role inheritance behavior.