Contents
The role in effect does have security implications. But changing a role for the duration of a query's execution, with ISOK_QUERIES.Role, has fewer security implications than it might seem.
Changing the current role does open up the possibility that
database objects to which the new role has access may be
changed.
But this door is already open.
A new role cannot be assumed without some chain of
SET option grants from the
session_user [definition here(-ish)]
to the current role.
So a malicious actor always has access to the same set of roles,
regardless of whether Isok is involved or not.
What might be surprising is that, even though a role may
SET ROLE to another, perhaps with less
privileges, it is always possible to use RESET
ROLE (or SET ROLE NONE) and reset
the current role to the session_role.
There is no sandboxing.
If the session sets a role before running run_isok_queries(), there is the possibility that a
malicious actor might undo the assumption of the role.
This could then affect the role used to execute any queries that
run_isok_queries() has not yet executed.
Don't expect that a SET ROLE to a role of lesser privileges makes running run_isok_queries() any safer.
Page generated: 2025-06-26T11:38:35-05:00.