GitHub user bharos created a discussion: Consider support for role assumption (SET ROLE) to narrow effective permissions
**Problem** When a user holds multiple roles, Gravitino evaluates all of them as a union for every authorization check. There is no way to restrict evaluation to a subset of roles for a given request or session. **Example:** A user has broad_role (100 tables) and restricted_role (5 tables). Today the user always sees all 105 tables. We want the ability to operate under only restricted_role's permissions — equivalent to Snowflake's [USE SECONDARY ROLE](https://docs.snowflake.com/en/sql-reference/sql/use-secondary-roles) / Hive's SET ROLE. **Current behavior** The authorization layer loads all roles granted to the authenticated user and evaluates them as a union. There is no mechanism to specify which role(s) should be active for a given request. This applies to both the Iceberg REST API and native Gravitino API paths. **Possible approach** Support an optional HTTP header (e.g., X-Gravitino-Active-Role) on Iceberg REST and native API requests: - Auth interceptor reads the header - Validate the user actually holds the specified role (prevent escalation) - If set, evaluate only the specified role's policies instead of all - No header = current behavior (fully backward compatible) This works with Iceberg clients (Trino, Spark) via RESTSessionCatalog's header.* catalog properties , no client code changes needed. However, the role is static per catalog configuration. Dynamic per-session role switching (like Snowflake's USE ROLE) would require either a server-side session API or client-side changes. The header approach can cover the case where different applications or contexts operate under different roles. **Alternative / longer-term direction** A header is a pragmatic first step. For full parity with Snowflake's USE ROLE — where users dynamically switch roles mid-session via SQL — the Iceberg REST catalog server would need session-aware role state, and engine connectors (Trino, Spark) would need to propagate SET ROLE to the server. That's a larger cross-project effort. Interested in gathering community's thoughts on this and hearing if there are other approaches being considered. GitHub link: https://github.com/apache/gravitino/discussions/10894 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
