2012/6/28 Tom Lane <t...@sss.pgh.pa.us>:
> Kohei KaiGai <kai...@kaigai.gr.jp> writes:
>> 2012/6/27 Florian Pflug <f...@phlo.org>:
>>> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
>
>> My impression is, here is no matter even if SECURITY DEFINER function
>> returns refcursor.
>
> I think Florian has a point: it *should* work, but *will* it?
>
> I believe it works today, because the executor only applies permissions
> checks during query startup. So those checks are executed while still
> within the SECURITY DEFINER context, and should behave as expected.
> Subsequently, the cursor portal is returned to caller and caller can
> execute it to completion, no problem.
>
> However, with RLS security-related checks will happen throughout the
> execution of the portal. They might do the wrong thing once the
> SECURITY DEFINER function has been exited.
>
I tried the scenario that Florian pointed out.
postgres=# CREATE OR REPLACE FUNCTION f_test(refcursor) RETURNS refcursor
postgres-# SECURITY DEFINER LANGUAGE plpgsql
postgres-# AS 'BEGIN OPEN $1 FOR SELECT current_user, * FROM t1;
RETURN $1; END';
CREATE FUNCTION
postgres=# BEGIN;
BEGIN
postgres=# SELECT f_test('abc');
f_test
--------
abc
(1 row)
postgres=# FETCH abc;
current_user | a | b
--------------+---+-----
kaigai | 1 | aaa
(1 row)
postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> FETCH abc;
current_user | a | b
--------------+---+-----
alice | 2 | bbb
(1 row)
postgres=> SET SESSION AUTHORIZATION bob;
SET
postgres=> FETCH abc;
current_user | a | b
--------------+---+-----
bob | 3 | ccc
(1 row)
Indeed, the output of "current_user" depends on the setting of session
authorization, even though it was declared within security definer
functions (thus, its security checks are applied on the privileges of
function owner).
> We might need to consider that a portal has a local value of
> "current_user", which is kind of a pain, but probably doable.
>
It seems to me, it is an individual matter to be fixed independent
from RLS feature. How about your opinion?
If we go ahead, an idea to tackle this matter is switch user-id
into saved one in the Portal at the beginning of PortanRun or
PortalRunFetch.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
