Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 10, 2023 at 8:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ squint ... ] Are you sure it's not a security *hazard*, though?
> I think you have to squint pretty hard to find a security hazard here.
Maybe, but I'd be sad if somebody manages to find one after this is
out in the wild.
> That said, in my original design, this was controlled via a different
> mechanism which was superuser-only. I was informed that made no sense,
> so I changed it. Now here we are.
Yeah. I concur that a SUSET GUC isn't much fun for a non-superuser
CREATEROLE holder who might wish to adjust the default behavior they get.
I also concur that it seems a bit far-fetched that a CREATEROLE holder
might create a SECURITY DEFINER function that would do something that
would be affected by this setting. Still, we have no field experience
with how these mechanisms will actually be used, so I'm worried.
The scenario I'm worried about could be closed, mostly, if we were willing
to invent an intermediate GUC privilege level "can be set interactively
but only by CREATEROLE holders" ("PGC_CRSET"?). But that's an awful lot
of infrastructure to add for one GUC. Are there any other GUCs where
that'd be a more useful choice than any we have now?
regards, tom lane