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

Re: [v9.3] Row-Level Security

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.3] Row-Level Security
Date: 2012-06-28 15:29:09
Message-ID: 13183.1340897349@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
> 2012/6/27 Florian Pflug <fgp(at)phlo(dot)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.

We might need to consider that a portal has a local value of
"current_user", which is kind of a pain, but probably doable.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-06-28 15:29:10
Subject: Re: experimental: replace s_lock spinlock code with pthread_mutex on linux
Previous:From: Robert HaasDate: 2012-06-28 15:26:00
Subject: Re: Posix Shared Mem patch

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