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.
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 left
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, which
* 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
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 the
* 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 written
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:
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
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 wonder
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
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
* 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
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
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 raising
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 all kinds
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.
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
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
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
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
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
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
* 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 some
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 function
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 down
* 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.
What about
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
27 matches
Mail list logo
