User grants: Privileges granted to a user apply regardless of secondary roles (Disabled by default)¶

When the 2026_08 bundle is enabled, privileges granted directly to a user with GRANT <privileges> … TO USER apply in that user’s sessions regardless of the secondary roles setting, and regardless of a session policy that disallows all secondary roles. The grants are activated in every session for that user.

Before the change:

Privileges granted directly to a user were effective only when the session had all secondary roles activated. A user with DEFAULT_SECONDARY_ROLES = () starts each session with no secondary roles. A session that ran USE SECONDARY ROLES NONE, or that activated a specific list of secondary roles, authorized SQL with the primary role and those secondary roles only. Privileges granted to the user didn’t apply.

A session policy that disallowed all secondary roles had the same effect, with ALLOWED_SECONDARY_ROLES = () or BLOCKED_SECONDARY_ROLES = ('ALL'). The policy kept those privileges from applying even when the session requested all secondary roles.

For example, user analyst has the primary role analyst_role. That role has no privilege on mydb.myschema.orders, and SELECT on that table is granted to analyst:

Copy code

GRANT USAGE ON DATABASE mydb TO USER analyst;
GRANT USAGE ON SCHEMA mydb.myschema TO USER analyst;
GRANT SELECT ON TABLE mydb.myschema.orders TO USER analyst;

In a session for analyst with secondary roles disabled, the query failed:

Copy code

USE ROLE analyst_role;
USE SECONDARY ROLES NONE;
SELECT * FROM mydb.myschema.orders;

002003 (02000): SQL compilation error:
Database 'MYDB' does not exist or not authorized. Your primary role ANALYST_ROLE must have USAGE or any other privilege granted on DATABASE MYDB.

After the change:

Those privileges are activated in every session for that user. DEFAULT_SECONDARY_ROLES = (), USE SECONDARY ROLES NONE, a specific secondary role list, and a session policy that disallows all secondary roles don’t apply to them. The same statements succeed:

Copy code

USE ROLE analyst_role;
USE SECONDARY ROLES NONE;
SELECT * FROM mydb.myschema.orders;

Sessions that already activated all secondary roles are unchanged, because those sessions already used privileges granted to the user.

This behavior change is most likely to affect accounts that grant privileges directly to users and that also restrict secondary roles. A session that relied on that restriction to keep user grants out of a workload now authorizes those grants.

How to update your code¶

Review users who have privileges granted with GRANT ... TO USER, including users with DEFAULT_SECONDARY_ROLES = (), and the sessions, tasks, and client connections that set secondary roles to NONE or to a specific list so that only the primary role and those listed roles authorize SQL. Also review session policies that disallow all secondary roles, with ALLOWED_SECONDARY_ROLES = () or BLOCKED_SECONDARY_ROLES = ('ALL'). That restriction doesn’t apply to privileges granted directly to the user.

To keep the previous behavior while the 2026_08 bundle is available for testing, disable the bundle. See Managing behavior change releases. For example:

SELECT SYSTEM$DISABLE_BEHAVIOR_CHANGE_BUNDLE('2026_08');

Disabling the bundle only defers this change. After the bundle is generally enabled, turning secondary roles off doesn’t exclude privileges granted to the user. A session policy that disallows all secondary roles doesn’t exclude them either. To keep the privilege when secondary roles are disabled, revoke it from the user and grant it to an account role, then grant that role to the user. Activate that role as the primary role. The primary role authorizes the privilege:

REVOKE SELECT ON TABLE mydb.myschema.orders FROM USER analyst;
GRANT SELECT ON TABLE mydb.myschema.orders TO ROLE orders_reader;
GRANT ROLE orders_reader TO USER analyst;
USE ROLE orders_reader;
USE SECONDARY ROLES NONE;
SELECT * FROM mydb.myschema.orders;

Ref: 2438