Everything in Unity Catalog lives in a metastore and is addressed through a three-level namespace, catalog.schema.table. Every object in that hierarchy is a securable, and access is expressed as privileges granted on securables.
Catalogs and schemas are container objects. Catalogs hold schemas; schemas hold tables, views, volumes and functions. Containers matter because a privilege granted on one applies automatically to all current and future children. Initially, users have no access to data in a metastore: a privilege must be explicitly granted before an action is allowed.
| Grant level | Flows down to | Behaviour worth remembering |
|---|---|---|
| Metastore | Nothing, with one exception | Controls metastore-scoped actions such as CREATE CATALOG and CREATE EXTERNAL LOCATION, not data access. READ METADATA is the exception and inherits to every object |
| Catalog | All schemas, then their tables, views, volumes and functions | Includes objects created later |
| Schema | All its tables, views, volumes and functions | Includes objects created later |
| Table, view, volume, function | Nothing | Non-container objects have no children |
Inheritance is what makes a small number of grants enough. A single statement can serve an entire domain, including tables nobody has created yet:
GRANT USE CATALOG, USE SCHEMA, SELECT
ON CATALOG sales TO finance_team;Denials inherit the same way: a privilege denied on a parent is denied on all current and future children, and these rules apply whether the privilege came from GRANT or from an attribute-based policy. Figure 15.1 shows where privileges flow and where they stop.
Common trap: Granting
CREATE CATALOGor a similar privilege on the metastore gives access to the data below it - metastore-level grants do not inherit to child objects and only control metastore-scoped operations.READ METADATAis the single exception, and even that exposes metadata, not data.
Usage privileges are a separate gate
USE CATALOG and USE SCHEMA are usage privileges, and they are a prerequisite for working with anything inside the container. For most operations, all three parts of the chain below are required; the MANAGE rows are the exception.
| Operation | Required privileges |
|---|---|
| Read a table or view | USE CATALOG, USE SCHEMA, SELECT |
| Execute a function | USE CATALOG, USE SCHEMA, EXECUTE |
| Create a table | USE CATALOG, USE SCHEMA, CREATE TABLE on the schema (or inherited from the catalog) |
| Manage a catalog | MANAGE on the catalog; no usage privileges |
| Manage a schema | USE CATALOG, MANAGE on the schema |
| Manage a table, view, volume or function | USE CATALOG, USE SCHEMA, MANAGE on the object |
Common trap:
SELECTon a table is enough to read it - the reader also needsUSE CATALOGon the catalog andUSE SCHEMAon the schema. A table-level grant on its own fails, and this is deliberate, because it stops table owners granting access outside the boundary set by higher-level administrators.
ALL PRIVILEGES and composite privileges
ALL PRIVILEGES implies all applicable privileges for an object type without granting each one explicitly. On a table it implies SELECT, MODIFY and APPLY TAG. It does not include MANAGE, READ METADATA, EXTERNAL USE SCHEMA or EXTERNAL USE LOCATION; the MANAGE exclusion exists to avoid accidental privilege escalation.
Composite privileges have children that grant a subset of their capability. MANAGE has the children READ METADATA and MANAGE ACCESS CONTROL, and MODIFY has the children INSERT, UPDATE and DELETE (Beta). Composite and child privileges are granted and revoked independently.
Revoking MODIFY therefore does not remove a DELETE privilege that was granted explicitly, so an access review has to look at composite and child privileges separately.