Roles
Prev | A. Security Considerations | Next

### Roles

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.

Prev | Up | Next
The Search Path | Home | Mitigation Strategies

Page generated: 2025-11-03T13:22:31-06:00.