2012/7/3 Robert Haas <robertmh...@gmail.com>: > On Mon, Jul 2, 2012 at 10:55 AM, Kohei KaiGai <kai...@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; > 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 <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
