Re: User-Id Tracking when Portal was started
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: PgHacker <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Florian Pflug <fgp@phlo.org>
Date: 2012-07-03T14:58:21Z
Lists: pgsql-hackers
On Mon, Jul 2, 2012 at 10:55 AM, Kohei KaiGai <kaigai@kaigai.gr.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 EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company