High-level caller privileges¶

In addition to fine-grained caller grants, an administrator can grant a small set of high-level caller privileges. Each high-level caller privilege authorizes a broad category of operations (for example, all read operations in a database) without the need to enumerate every individual caller grant.

The following high-level caller privileges can be granted with a GRANT CALLER statement.

Hierarchy¶

High-level caller privileges form a containment hierarchy: an ancestor implicitly covers every operation allowed by its descendants, so granting an ancestor automatically authorizes everything the descendants would.

FULL MANAGEMENT
└── OBJECT MANAGEMENT
│    ├── DATA WRITE
│    │     └── DATA READ
│    └── COMPUTE USAGE
├── GRANT MANAGEMENT
└── PROGRAM USAGE

DATA READ¶

The DATA READ high-level caller privilege authorizes an RCR executable to read data from objects in the target container, This currently includes tables, views, streams, stages, and workspaces.

DATA READ doesn’t authorize any of the following:

• Writing or modifying data.
• Creating or altering objects.
• Running GRANT or REVOKE statements.
• Invoking executables.

DATA READ can be granted on an account, database, or schema. It is implicitly covered by DATA WRITE, OBJECT MANAGEMENT, and FULL MANAGEMENT.

The following example lets all RCR executables owned by rpt_owner read data in the reporting database:

GRANT CALLER DATA READ ON DATABASE reporting TO ROLE rpt_owner;

DATA WRITE¶

The DATA WRITE high-level caller privilege authorizes an RCR executable to write data to objects in the target container. This currently includes tables only. It implicitly covers DATA READ.

DATA WRITE doesn’t authorize any of the following:

• Creating or altering objects.
• Running GRANT or REVOKE statements.
• Invoking executables.

DATA WRITE can be granted on an account, database, or schema. It is implicitly covered by OBJECT MANAGEMENT and FULL MANAGEMENT.

The following example lets all RCR executables owned by etl_owner read from any schema in the raw database and write to tables in the curated.silver schema:

GRANT CALLER DATA READ  ON DATABASE raw            TO ROLE etl_owner;
GRANT CALLER DATA WRITE ON SCHEMA   curated.silver TO ROLE etl_owner;

COMPUTE USAGE¶

The COMPUTE USAGE high-level caller privilege authorizes an RCR executable to use compute resources. This currently includes warehouses and compute pools.

COMPUTE USAGE can only be granted on an account. It is implicitly covered by OBJECT MANAGEMENT and FULL MANAGEMENT.

PROGRAM USAGE¶

The PROGRAM USAGE high-level caller privilege authorizes an RCR executable to invoke certain executables in the target container. This currently includes:

• User-defined functions (UDFs) and user-defined table functions (UDTFs).
• Stored procedures.
• Streamlit in Snowflake apps.

PROGRAM USAGE can be granted on an account, database, or schema. It is implicitly covered by FULL MANAGEMENT.

GRANT MANAGEMENT¶

The GRANT MANAGEMENT high-level caller privilege authorizes an RCR executable to do the following on in-account objects in the target container:

• Run GRANT and REVOKE statements for permissions.
• Create transient and persistent references.
  • The reference’s privileges and object must be covered by caller grants.

The following sensitive grants aren’t covered by GRANT MANAGEMENT and require FULL MANAGEMENT instead:

• Grants on accounts and account roles
• Grants to shares and shared database roles
• Ownership transfer of executables
• Caller grants

GRANT MANAGEMENT can be granted on an account, database, or schema. It is implicitly covered by FULL MANAGEMENT.

The following example shows the caller grants that allow an RCR executable owned by data_owner to create a SELECT reference, but not an INSERT reference, on a table in the data schema:

GRANT CALLER DATA READ        ON SCHEMA data TO ROLE data_owner;
GRANT CALLER GRANT MANAGEMENT ON SCHEMA data TO ROLE data_owner;

-- Allowed:
SELECT SYSTEM$REFERENCE('TABLE', 'data.raw', 'PERSISTENT', 'SELECT');

-- Blocked: no CALLER DATA WRITE grant.
SELECT SYSTEM$REFERENCE('TABLE', 'data.raw', 'PERSISTENT', 'INSERT');

OBJECT MANAGEMENT¶

The OBJECT MANAGEMENT high-level caller privilege authorizes an RCR executable to take full control of non-sensitive objects in the target container. It implicitly covers DATA READ, DATA WRITE, and COMPUTE USAGE.

With exceptions (see below), OBJECT MANAGEMENT allows:

• All operations on all objects inside accounts (but not including accounts themselves).
• Creation of objects inside accounts.

OBJECT MANAGEMENT doesn’t cover the following sensitive operations. They require FULL MANAGEMENT instead:

• Alteration of the account.
• Creation or alteration of integrations, listings, shares, and users.
• Creation of executables (including, but not limited to, procedures, UDFs, UDTFs, tasks, alerts, Streamlit in Snowflake apps, services, service classes, agents, MCP servers, dbt projects, DCM projects, notebooks, and notebook projects).
• Invocation of executables not covered by PROGRAM USAGE.
• Execution of a job service.
• Creation of a programmatic access token (PAT).
• Alteration of the EXECUTE AS property of executables.
• Writing to stages, repositories, and workspaces.

OBJECT MANAGEMENT can be granted on an account, database, or schema. It is implicitly covered by FULL MANAGEMENT.

The following example lets a Snowflake Native App provision and grant access to objects in its database:

GRANT CALLER OBJECT MANAGEMENT ON DATABASE my_app_db TO APPLICATION my_app;
GRANT CALLER GRANT  MANAGEMENT ON DATABASE my_app_db TO APPLICATION my_app;

FULL MANAGEMENT¶

The FULL MANAGEMENT high-level caller privilege authorizes an RCR executable to perform every operation in the account. It implicitly covers all other high-level caller privileges.

FULL MANAGEMENT can only be granted on an account.

Operations and the required high-level caller privilege¶

The following operations were previously blocked inside an RCR executable and are now allowed only when the executable owner holds at least the high-level caller privilege shown. These operations may be authorized by regular permissions, but they aren’t authorized by the corresponding caller permissions. For example, CALLER CREATE PROCEDURE ON SCHEMA doesn’t allow the creation of a procedure. Only CALLER FULL MANAGEMENT does.

Adding new privileges to a high-level caller privilege¶

When Snowflake introduces a new privilege or object type, it might be added to an existing high-level caller privilege. This expands the set of operations that an existing grant authorizes. Snowflake documents the intent of each high-level caller privilege rather than an exhaustive list of covered operations, and adding new members is generally not treated as a behavior change release (BCR).

When granting a high-level caller privilege, reason about the operations you want to authorize in terms of the description of the privilege, not a fixed permission list.