On Thu, 2023-07-06 at 18:39 -0700, Jeff Davis wrote: > * The fix might not go far enough or might be in the wrong place. I'm > open to suggestion here, too. Maybe we can make it part of the > general > function call mechanism, and can be overridden by explicitly setting > the function search path? Or maybe we need new syntax where the > function can acquire the search path from the session explicitly, but > uses a safe search path by default?
I'm inclined to proceed with the current approach here, which is to just fix search_path for maintenance commands. Other approaches may be possible, but: (a) We already special-case the way functions are executed for maintenance commands in other ways -- we run the functions as the table owner (even SECURITY INVOKER functions) and run them as a SECURITY_RESTRICTED_OPERATION. Setting the search_path to a safe value seems like a natural extension of that; and (b) The lack of a safe search path is blocking other useful features, such as the MAINTAIN privilege; and (c) I don't see other proposals, aside from a few ideas I put forward here[1], which didn't get any responses. The current approach seemed to get support from Noah, Nathan, and Greg Stark. Concerns were raised by Gurjeet, Tom, and Robert in the 16 cycle; but I'm not sure whether those objections were specific to the 16 cycle or whether they are objections to the approach entirely. Comments? Regards, Jeff Davis [1] https://www.postgresql.org/message-id/6781cc79580c464a63fc0a1343637ed2b2b0cf09.camel%40j-davis.com