Skip site navigation (1) Skip section navigation (2)

Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Kohei(dot)Kaigai(at)emea(dot)nec(dot)com, thom(at)linux(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)
Date: 2012-01-18 03:28:45
Message-ID: CA+TgmoY-UZe6TQOwgWT2k-dHfZwa6nKnq-2H+03Czy0a=FBrug@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jan 8, 2012 at 10:52 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>> BTW, can you also resubmit the leakproof stuff as a separate patch for
>>> the last CF?  Want to make sure we get that into 9.2, if at all
>>> possible.
>>>
>> Yes, it shall be attached on the next message.
>>
> The attached patch adds LEAKPROOF attribute to pg_proc; that
> enables DBA to set up obviously safe functions to be pushed down
> into sub-query even if it has security-barrier attribute.
> We assume this LEAKPROOF attribute shall be applied on operator
> functions being used to upgrade execute plan from Seq-Scan to
> Index-Scan.
>
> The default is without-leakproof attribute on creation of functions,
> and it requires superuser privilege to switch on.

The create_function_3 regression test fails for me with this applied:

*** /Users/rhaas/pgsql/src/test/regress/expected/create_function_3.out
 2012-01-17 22:09:01.000000000 -0500
--- /Users/rhaas/pgsql/src/test/regress/results/create_function_3.out
 2012-01-17 22:14:48.000000000 -0500
***************
*** 158,165 ****
                       'functext_E_2'::regproc);
     proname    | proleakproof
  --------------+--------------
-  functext_e_2 | t
   functext_e_1 | t
  (2 rows)

  -- list of built-in leakproof functions
--- 158,165 ----
                       'functext_E_2'::regproc);
     proname    | proleakproof
  --------------+--------------
   functext_e_1 | t
+  functext_e_2 | t
  (2 rows)

  -- list of built-in leakproof functions
***************
*** 476,485 ****
                       'functext_F_4'::regproc);
     proname    | proisstrict
  --------------+-------------
-  functext_f_1 | f
   functext_f_2 | t
   functext_f_3 | f
   functext_f_4 | t
  (4 rows)

  -- Cleanups
--- 476,485 ----
                       'functext_F_4'::regproc);
     proname    | proisstrict
  --------------+-------------
   functext_f_2 | t
   functext_f_3 | f
   functext_f_4 | t
+  functext_f_1 | f
  (4 rows)

  -- Cleanups

The new regression tests I just committed need updating as well.

Instead of contains_leakable_functions I suggest
contains_leaky_functions or contains_non_leakproof_functions, because
"leakable" isn't really a word (although I know what you mean).

The design of this function also doesn't seem very future-proof.  If
someone adds a new node type that can contain a function call, and
forgets to add it here, then we've got a subtle security hole.  Is
there some reasonable way to design this so that we assume
everything's dangerous except for those things we know are safe,
rather than the reverse?

I think you need to do a more careful check of which functions you're
marking leakproof - e.g. timestamp_ne_timestamptz isn't, at least
according to my understanding of the term.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Nikhil SontakkeDate: 2012-01-18 05:10:04
Subject: Re: how to create a non-inherited CHECK constraint in CREATE TABLE
Previous:From: Robert HaasDate: 2012-01-18 03:08:35
Subject: Re: [v9.2] Fix Leaky View Problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group