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

Re: User-Id Tracking when Portal was started

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Florian Pflug <fgp(at)phlo(dot)org>
Subject: Re: User-Id Tracking when Portal was started
Date: 2012-07-03 14:58:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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;

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-03 15:02:15
Subject: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes
Previous:From: Jeff DavisDate: 2012-07-03 14:26:08
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree

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