On Wed, Jun 12, 2024 at 2:05 PM John H <johnh...@gmail.com> wrote:> > I'm sympathetic to the problem of potential privilege escalation when > executing functions. At the same time I'm not sure if there's that > much of a difference between 'CREATE EXTENSION' vs superusers copying > a series of 'CREATE FUNCTION' where they don't understand these same > nuances.
+1. > CREATE FUNCTION already provides an ability to set the search_path. So > I'm wondering what the problem we want to solve here is. Is it that > there's too much friction for extension authors to have to set > search_path as part of the function definition and we want to make it > easier for them to "set once and forget"? If that's the problem we want to solve, I'm unconvinced that it's worth doing anything. But I think there's another problem, which is that if the extension is relocatable, how do you set a secure search_path? You could say SET search_path = foo, pg_catalog if you know the extension will be installed in schema foo, but if you don't know in what schema the extension will be installed, then what are you supposed to do? The proposal of litting $extension_schema could help with that ... ...except I'm not sure that's really a full solution either, because what if the extension is installed into a schema that's writable by others, like public? If $extension_schema resolves to public and public allows CREATE access to normal users, you're in a lot of trouble again already, because now an attacker can try to capture operator references within your function, or function calls that are approximate matches to some existing function by introducing perfect matches that take priority. Perhaps we want to consider the case where the attacker can write to the schema containing the extension as an unsupported scenario, but if so, we'd better be explicit about that. -- Robert Haas EDB: http://www.enterprisedb.com
