From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Fixing insecure security definer functions |
Date: | 2007-05-29 19:57:29 |
Message-ID: | 20070529195729.GU7531@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom, Josh,
* Josh Berkus (josh(at)agliodbs(dot)com) 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 could be developed now or later:
I agree.
> 1) pg_get_caller_path() == returns the search_path of the calling session,
> which presumably is being stored somewhere for reversion when the final
> nested function exits.
I'd be happy to take a look at this but it depends on knowing where in
the backend the caller's search_path is stashed (which it has to be to
be reset at the end, I'd expect...), which depends on the implementation
of function_path. I don't recall seeing that committed to CVS yet (though
perhaps I missed it).
> 2) pg_get_object_fullname(name, path) == returns the fully-qualified object
> name of an object based on the path supplied.
I think this particular function would be useful in a number of cases,
honestly. :)
> However, I don't see this as being anything which would hold up 8.3, since
> function_path doesn't break anything which was already working.
Agreed, never intended it to imply there was something wrong with
function_path, just a nice addition to better support certain
applications (mine, at the least :).
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-29 20:01:45 | Re: Padding on 64-bit |
Previous Message | Magnus Hagander | 2007-05-29 19:46:31 | Re: Padding on 64-bit |