Unity Catalog Privileges: Namespace, Usage Rules and Inheritance

1.The three-level namespace and securable objects

In Unity Catalog, all data and metadata sit inside a top-level container called a metastore. Inside the metastore, data is addressed through a three-level namespace, catalog.schema.table. That name is also how access works. Every object in the hierarchy is a securable object, so you can grant privileges such as SELECT, MODIFY or USE SCHEMA on it to a principal: a user, a service principal or a group.

Unity Catalog has two kinds of securable object. Container objects hold other objects. Catalogs are the top level and contain schemas. Schemas are the middle level and contain tables, views, volumes and functions as direct children. Non-container objects are tables, views, volumes and functions, and they contain nothing. So a volume sits beside a table, one level below a schema. The difference matters because privileges granted on a container can reach its children, which later sections cover.

Privileges are not the only control. Unity Catalog combines four models. Privileges and ownership decide *who* can access *what*. Attribute-based (ABAC) policies use governed tags to decide what data users can access. Table-level row filters and column masks control what users see inside a table. Workspace bindings decide *where* objects can be reached from. This lesson covers privileges, ownership and roles. Tag-driven policies and masking have their own lesson.

Sources12

2.Usage privileges: why SELECT alone is not enough

Nothing in Unity Catalog is allowed by default. A user or group must be explicitly granted a privilege before it can perform an action. The common privileges are SELECT (read from tables or views), MODIFY (write to tables or views), CREATE TABLE (create tables in a schema), and the two usage privileges, USE CATALOG and USE SCHEMA.

Usage privileges open a container. They give no access to data by themselves. To work with any object in a catalog, you need USE CATALOG on that catalog. To work with any object in a schema, you need USE SCHEMA on that schema. Most operations on a table, view, volume or function therefore need three grants: USE CATALOG on the parent catalog, USE SCHEMA on the parent schema, and the privilege for the operation itself, such as SELECT, MODIFY, EXECUTE or READ VOLUME.

This rule also lets administrators set boundaries. A table owner might want to share their table, but other users still can't reach it without USE CATALOG and USE SCHEMA on the parents. Only catalog and schema owners, or users with MANAGE, can grant those usage privileges. That stops table owners from granting access outside approved boundaries.

Sources13

3.Inheritance, ALL PRIVILEGES and BROWSE

Yes. A privilege granted on a container object automatically applies to all current *and future* child objects. For example, SELECT granted on a catalog lets the grantee read every table in that catalog, provided they also hold the usage privileges. This is why containers also accept privileges that apply to objects inside them. You can grant SELECT, MODIFY, EXECUTE or READ VOLUME at the catalog or schema level, and they cover objects created later as well. Containers also have creation privileges, such as CREATE SCHEMA on a catalog and CREATE TABLE on a schema.

ALL PRIVILEGES covers every applicable privilege for an object type, and you don't have to list each one. On a table it implies SELECT, MODIFY and APPLY TAG. On a volume it implies READ VOLUME, WRITE VOLUME and APPLY TAG. It does not include everything, though. EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE and READ METADATA are excluded.

Some privileges are composite, and each has narrower child privileges. MODIFY is the composite for INSERT, UPDATE and DELETE (Beta). MANAGE is the composite for READ METADATA and MANAGE ACCESS CONTROL. Composite and child privileges are granted and revoked independently. Granting the composite does not grant its children, and revoking the composite does not remove a child that was granted explicitly.

BROWSE separates finding data from reading it. A user with BROWSE can see that an object exists, view its name, description and tags, and request access, without USE CATALOG or USE SCHEMA. BROWSE gives no access to the data itself. It is granted at the catalog level, and Databricks recommends granting BROWSE on catalogs to the All account users group so data is discoverable across the organization.

Sources1

4.Granting, revoking and inspecting privileges

You can manage privileges with SQL commands, the Databricks CLI, the Databricks Terraform provider or Catalog Explorer. In SQL the pattern is GRANT <privilege-type> ON <securable-type> <securable-name> TO <principal>. The principal is a user, a service principal (identified by its applicationId) or a group. Names that contain special characters, such as a hyphen, must be enclosed in backticks.

The example below gives the group finance-team everything it needs to create tables in main.default. Because of the usage rule, CREATE TABLE alone would not be enough, so the example also grants USE SCHEMA and USE CATALOG.

GRANT CREATE TABLE ON SCHEMA main.default TO `finance-team`;
  GRANT USE SCHEMA ON SCHEMA main.default TO `finance-team`;
  GRANT USE CATALOG ON CATALOG main TO `finance-team`;

SHOW GRANTS ON SCHEMA main.default; lists the grants on an object. You see all of them only if you are a metastore admin, hold READ METADATA or MANAGE on the object, own it, or own its parent catalog or schema. Anyone else sees only their own grants. REVOKE <privilege-type> ON <securable-type> <securable-name> FROM <principal> removes a privilege. A REVOKE succeeds even when the privilege was never granted, because it only guarantees that the privilege is absent afterwards.

Registered models are a special case. They are a type of function, so you grant on them with ON FUNCTION.

In Catalog Explorer the grant flow is: click Catalog, select the object, open the Permissions tab, click Grant, enter a user's email or a group name, select the permissions, and click OK.

REVOKE CREATE TABLE ON SCHEMA main.default FROM `finance-team`;

GRANT EXECUTE ON  ?  prod.ml_team.iris_model TO `ml-team-acme`;

Sources4

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Granting SELECT on a table is enough for a user to query it.Why is that wrong?

   The user also needs USE CATALOG on the parent catalog and USE SCHEMA on the parent schema. Usage privileges are a prerequisite for every object below them.

   Covered in Usage privileges: why SELECT alone is not enough

2. 2.ALL PRIVILEGES makes the grantee able to manage permissions on the object.Why is that wrong?

   ALL PRIVILEGES excludes MANAGE and READ METADATA, as well as the two external-use privileges. Managing grants needs MANAGE or ownership.

   Covered in Inheritance, ALL PRIVILEGES and BROWSE

3. 3.Privileges on a registered model are granted with GRANT ... ON MODEL.Why is that wrong?

   Registered models are a type of function, so the grant uses ON FUNCTION.

   Covered in Granting, revoking and inspecting privileges