On Fri, Mar 24, 2023 at 12:17 PM Jelte Fennema <postgres@jeltef.nl> wrote:
> I personally cannot think of a reasonable example that would be
> broken, but I agree the code is simple enough. I do think that if
> there is an actual reason to do this, we'd probably want it in other
> places where SECURITY_RESTRICTED_OPERATION is enforced too.
I don't think it makes sense for this patch to run around and try to
adjust all of those other pages. We have to pick between doing it this
way (and thus being inconsistent with what we do elsewhere) or taking
that logic out (and taking our chances that something will break for
some users). I'm OK with either of those, but I'm not OK with going
and changing the way this works in all of the other cases first and
only then coming back to this problem. This problem is WAY more
important than fiddling with the details of how
SECURITY_RESTRICTED_OPERATION is applied.
> I think there's some important tests missing related to this:
> 1. Ensuring that SECURITY_RESTRICTED_OPERATION things are enforced
> when the user **does not** have SET ROLE permissions to the
> subscription owner, e.g. don't allow SET ROLE from a trigger.
> 2. Ensuring that SECURITY_RESTRICTED_OPERATION things are not enforced
> when the user **does** have SET ROLE permissions to the subscription
> owner, e.g. allows SET ROLE from trigger.
Yeah, if we stick with the current approach we should probably add
tests for that stuff.
--
Robert Haas
EDB: http://www.enterprisedb.com
