2012/7/3 Robert Haas <[email protected]>: > On Mon, Jul 2, 2012 at 10:55 AM, Kohei KaiGai <[email protected]> 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 <[email protected]> -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
