Thanks for the info
Ron Coffin, Lab Manager
School of Computer and Engineering Technologies
Miami Dade College, North Campus
11380 N.W. 27th Avenue
Miami, Florida 33167
Email: [EMAIL PROTECTED]
Phone: 305 237-1054
Fax: 305 237-1531
Please Note: Due to Florida's very broad public records law, mos
On Sat, Feb 17, 2007 at 11:31:19AM -0700, Michael Fuhr wrote:
> If you schema-qualify objects instead of setting search_path then
> don't forget about operators.
I knew I had missed something.
> SELECT col
> FROM schemaname.tablename
> WHERE othercol operator(pg_catalog.=) schemaname.funcname(
On Sat, Feb 17, 2007 at 03:15:25PM +0100, Karsten Hilbert wrote:
> On Sat, Feb 17, 2007 at 01:26:34PM +0900, Tatsuo Ishii wrote:
> > But if we insert a set schema search_path command in an SQL function,
> > the caller will be affected by it. Doing reset search_path before
> > returning to caller mi
On Sat, Feb 17, 2007 at 01:26:34PM +0900, Tatsuo Ishii wrote:
> But if we insert a set schema search_path command in an SQL function,
> the caller will be affected by it. Doing reset search_path before
> returning to caller might solve some of problems, but it will not
> recover caller's special s
> It has come to the attention of the core team of the PostgreSQL project
> that insecure programming practice is widespread in SECURITY DEFINER
> functions. Many of these functions are exploitable in that they allow
> users that have the privilege to execute such a function to execute
> arbit
Peter Eisentraut wrote:
The proper fix for this problem is to insert explicit SET search_path
commands into each affected function to produce a known safe schema
search path. Note that using the default search path, which includes a
reference to the "$user" schema, is not safe when unqualified
