On Fri, Mar 24, 2023 at 12:17 PM Jelte Fennema <postg...@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
