3. Add optional clauses to CREATE FUNCTION and ALTER FUNCTION to specify
the propath value. I suggest, but am not wedded to,
PATH 'foo, bar'
PATH NONE
Since PATH NONE is the default, it's not really needed in CREATE
FUNCTION, but it seems useful to allow it for ALTER FUNCTION.
Tom, Josh,
* Josh Berkus ([EMAIL PROTECTED]) wrote:
> Based on further IRC, I can personally see a solution which would be
> generally useful. Further, this solution doesn't require (or shouldn't)
> any modification of the existing function_path solution. It just requires
> two functions, whi
Stephen, Tom,
> > Eeek. *Which* caller's search_path? The string you're handed
> > might've come from multiple levels up.
>
> I would say the outer-most. If people inbetween want to mess with
> things, let them qualify it before handing it down. Clearly, an
> already-qualified object would be
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The 'special' bit here is that pg_getfullpath() would work relative to
> > the caller's search_path even inside of a function which has its 'PATH'
> > set.
>
> Eeek. *Which* caller's search_path? The string you
Stephen Frost <[EMAIL PROTECTED]> writes:
> The 'special' bit here is that pg_getfullpath() would work relative to
> the caller's search_path even inside of a function which has its 'PATH'
> set.
Eeek. *Which* caller's search_path? The string you're handed might've
come from multiple levels up.
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > It would be useful to have a function which could be passed a relative
> > (to the caller's search path) object name and would return the fully
> > qualified name of that object. In this way, functions could be w
Stephen Frost <[EMAIL PROTECTED]> writes:
> It would be useful to have a function which could be passed a relative
> (to the caller's search path) object name and would return the fully
> qualified name of that object. In this way, functions could be written
> which take relative arguments from th
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I would like to fix this for 8.3. I don't have a patch yet but want
> to get buy-in on a design before feature freeze. I propose the
> following, fully-backward-compatible design:
[...]
> Comments?
In talking w/ Jeff Davis on IRC today, another thought occ
Stephen Frost wrote:
> While I agree that raising a warning makes sense I don't believe it
> should be forced. There may be cases where, even in security definer
> functions, the current search_path should be used (though, of course,
> care must be taken in writing such functions).
I really wonde
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Merlin Moncure ([EMAIL PROTECTED]) wrote:
>> maybe security definer functions should raise a warning for implicit
>> PATH NONE, and possibly even deprecate that behavior and force people
>> to type it out in future (8.4+) releases.
> While I agree that
On 3/29/07, Stephen Frost <[EMAIL PROTECTED]> wrote:
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
> fwiw, I think this is a great solution...because the default behavior
> is preserved you get through without any extra guc settings (although
> you may want to add one anyways).
I agree that the pr
* Merlin Moncure ([EMAIL PROTECTED]) wrote:
> fwiw, I think this is a great solution...because the default behavior
> is preserved you get through without any extra guc settings (although
> you may want to add one anyways).
I agree that the proposed solution looks good.
> maybe security definer f
On 3/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
As was pointed out awhile ago
http://archives.postgresql.org/pgsql-general/2007-02/msg00673.php
it's insecure to run a SECURITY DEFINER function with a search_path
setting that's under the control of someone who wishes to subvert
the function. Even
As was pointed out awhile ago
http://archives.postgresql.org/pgsql-general/2007-02/msg00673.php
it's insecure to run a SECURITY DEFINER function with a search_path
setting that's under the control of someone who wishes to subvert
the function. Even for non-security-definer functions, it seems
usef
On 2/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> yikes!
> If you guys go through with forcing functions to attach to objects
> when they are created, it will break almost every project I've ever
> worked on :(. The schema/function combo fits into al
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> yikes!
> If you guys go through with forcing functions to attach to objects
> when they are created, it will break almost every project I've ever
> worked on :(. The schema/function combo fits into all kinds of de
> facto partitioning strategies and
On 2/13/07, Tom Lane <[EMAIL PROTECTED]> 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.
Andreas,
> Have you considered hardcoding the schema for each object where it was
> found at creation time ? This seems more intuitive to me.
This isn't practical. Consider the schema qualification syntax for
operators.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
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 speci
Am Mittwoch, 14. Februar 2007 10:21 schrieb Zeugswetter Andreas ADI SD:
> Have you considered hardcoding the schema for each object where it was
> found at creation time ?
Unless anyone has solved the halting problem lately, I don't think it's
possible to determine at creation time which objects
> Regarding the advisory on possibly insecure security definer functions
> that I just sent out (by overriding the search path you can make the
> function do whatever you want with the privileges of the function
> owner), the favored solution after some initial discussion in the core
> team wa
Peter Eisentraut wrote:
> Regarding the advisory on possibly insecure security definer functions
> that I just sent out (by overriding the search path you can make the
> function do whatever you want with the privileges of the function
> owner), the favored solution after some initial discussion in
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > It'll break most of the functions that we have in our production
> > systems... They're not security definer functions but it's routine for
> > us to switch between different schemas to run a function on.
>
> >
Stephen Frost <[EMAIL PROTECTED]> writes:
> It'll break most of the functions that we have in our production
> systems... They're not security definer functions but it's routine for
> us to switch between different schemas to run a function on.
> What about pushing all the in-function references
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Peter Eisentraut ([EMAIL PROTECTED]) wrote:
>> Regarding the advisory on possibly insecure security definer functions
>> that I just sent out (by overriding the search path you can make the
>> function do whatever you want with the privileges of the fun
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> Regarding the advisory on possibly insecure security definer functions
> that I just sent out (by overriding the search path you can make the
> function do whatever you want with the privileges of the function
> owner), the favored solution after s
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
owner), the favored solution after some initial discussion in the core
team was to save t
27 matches
Mail list logo
