2012/7/3 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Jul 2, 2012 at 10:55 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> The attached patch is delivered from the discussion around row-level
>> access control feature. A problem Florian pointed out is refcursor
>> declared in security definer function. Even though all the permission
>> checks are applied based on privilege of the owner of security-definer
>> function in case when it tries to define a cursor bound to a particular
>> query, it shall be executed under the credential of executor.
>> In the result, "current_user" or "has_table_privilege()" will return
>> unexpected result, even if it would be used in as a part of security
>> policy for each row.
>
> Why not just save and restore the user ID and security context
> unconditionally, instead of doing this kind of dance?
>
> +               if (portal->userId != GetUserId())
> +                       SetUserIdAndSecContext(portal->userId, portal->secCo
> +               else
> +                       saveUserId = InvalidOid;
>
In case when CurrentUserId was updated during the code block
(E.g, execution of SET SESSION AUTHORIZATION), it overwrites
this update on restoring user-id and security-context.

Comparison of user-id is a simple marker to check whether this
portal contain an operation to switch user-id, because these
operations are prohibited within security restricted context.
(Is there some other good criteria?)

Thanks,
-- 
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

• Re: User-Id Tracking when Portal was started at 2012-07-03 14:58:21 from Robert Haas

Responses

• Re: User-Id Tracking when Portal was started at 2012-07-03 15:36:42 from Tom Lane

pgsql-hackers by date

Next:	From: Robert Haas	Date: 2012-07-03 15:33:20
	Subject: Re: [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc
Previous:	From: Robert Haas	Date: 2012-07-03 15:28:50
	Subject: Re: Incorrect behaviour when using a GiST index on points