Date: Tue, 3 Jan 2023 14:03:11 -0800
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>
Subject: Re: allowing for control over SET ROLE
Message-ID: <20230103220311.GA1678742@rfd.leadboat.com>
References: <CA+Tgmoa9v2sSnNytiR1mwXE61_c+Kuqy=X-0gmvFsgXtf1yxBg@mail.gmail.com>
 <20221012205937.GA1548617@nathanxps13>
 <Y0wyfnpSYtoYcXNW@tamriel.snowman.net>
 <CA+TgmoZ9Jje8CYR=_2aG5nk0Vg-b5u+7c+YcH+bnFQJ7ODEJ2w@mail.gmail.com>
 <CA+TgmoYbYiHeWMdxbc73Ga6cNO4p6xWEYOLXXZCQfwmeNFzK2w@mail.gmail.com>
 <3e0e07334e2c4990491a8cbdef20dd89993a232a.camel@j-davis.com>
 <CA+TgmoYwVmk1VPb5ZV6aLAchRs80Dd2h3X3w49rPncqVojMJng@mail.gmail.com>
 <2428449680f732836906cebe9c8bf0998c7e5486.camel@j-davis.com>
 <20221231061640.GA1435002@rfd.leadboat.com>
 <CA+TgmoY3ZStmtErYccRtSXJpR6CRhNNqkKdr1aC9pKj04Uqyug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+TgmoY3ZStmtErYccRtSXJpR6CRhNNqkKdr1aC9pKj04Uqyug@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://www.postgresql.org/message-id/20230103220311.GA1678742%40rfd.leadboat.com>
Precedence: bulk

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.