From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fixing insecure security definer functions |
Date: | 2007-02-14 18:59:22 |
Message-ID: | 1171479562.10824.137.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2007-02-13 at 20:01 -0500, Tom Lane wrote:
> I would suggest that the search path be added as an explicit parameter
> to CREATE FUNCTION, with a default of the current setting. The main
> reason for this is that it's going to be a real PITA for pg_dump if we
> don't allow an explicit specification.
>
> It might also be worth allowing "PATH NULL" or some such locution to
> specify the current behavior, for those who really want it. (In
> particular, most C functions would want this to avoid useless overhead
> for calls to things that aren't affected by search path.)
>
It might also be useful to allow something such as PATH CURRENT to
attach the current schema as the search path for all calls of that
function.
This would be useful because then SQL scripts for installing 3rd party
modules could install nicely into any schema by merely setting
search_path before running the script.
For instance, PostGIS doesn't support installing into a schema other
than "public" because they want to have a static SQL install script
rather than generate one based on your desired search path.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | bjarne | 2007-02-14 19:06:45 | Re: Writing triggers in C++ |
Previous Message | Bruce Momjian | 2007-02-14 18:56:03 | Re: HOT WIP Patch - version 1 |