MIME-Version: 1.0
References: <CA+Tgmob+zDSRS6JXYrgq0NWdzCXuTNzT5eK54Dn2hhgt17nm8A@mail.gmail.com>
 <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>
In-Reply-To: <20221231061640.GA1435002@rfd.leadboat.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Tue, 3 Jan 2023 14:43:10 -0500
Message-ID: <CA+TgmoY3ZStmtErYccRtSXJpR6CRhNNqkKdr1aC9pKj04Uqyug@mail.gmail.com>
Subject: Re: allowing for control over SET ROLE
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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoY3ZStmtErYccRtSXJpR6CRhNNqkKdr1aC9pKj04Uqyug%40mail.gmail.com>
Precedence: bulk

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