What you will be able to do
- Identify every principal who can grant privileges on a Unity Catalog object, including owners of the parent catalog or schema
- Explain how MANAGE is inherited from containers and which usage privileges it does and does not remove
- Avoid common mistakes about what ALL PRIVILEGES includes and about composite and child privileges
- Apply Databricks' recommended practices for designing grants around the hierarchy
1.Who can grant: ownership follows the hierarchy too
Every securable object in Unity Catalog has an owner. An object's creator is its first owner, and the owner has all privileges on the object, including the right to grant privileges to others. Owner authority also follows the container hierarchy in one specific way: owning a container means you automatically get the ability to manage all of its child objects, even child objects you don't own yourself.
Ownership itself does not inherit downward. If you own a catalog, you don't automatically own its schemas. You can manage them, but you don't automatically own them, and you don't automatically hold data privileges on them.
The documentation lists four kinds of principal who can grant privileges on an object:
- the owner of the object
- the owner of the catalog or schema that contains the object
- a user with the MANAGE privilege on the object
- a metastore admin
Account admins can also grant privileges directly on a metastore. The same four can view an object's grants with SHOW GRANTS or revoke them with REVOKE. Separately, the READ METADATA privilege lets its holder view an object's metadata, including permissions, without being able to modify the object or read its data. A REVOKE succeeds even if the privilege was never granted. It simply makes sure the privilege is not present.
Checkpoint 1 of 5· Check yourself
Priya created the table prod.sales.orders and owns it. Marco owns the schema prod.sales but has no grant on the table. Which statement is correct?
Owners of parent catalogs and schemas can grant privileges on all objects inside them, including objects they do not own.
“Owners of parent catalogs and schemas also have the ability to grant privileges on all objects in the catalog or schema.”Source: docs.databricks.com
2.MANAGE: inherited management without full ownership
MANAGE lets a principal manage privileges on an object, transfer its ownership and drop it without being the owner. Unlike ownership, MANAGE can be granted to more than one principal. Like other container grants, it inherits: if MANAGE is granted on a container, the user also gets MANAGE on all of that container's children.
MANAGE does not give the holder all privileges on the object. Privileges must be granted separately, but a user with MANAGE can explicitly grant themselves data access privileges such as SELECT. So MANAGE doesn't let you read data directly, yet it is a short step away from it.
Ownership behaves differently from MANAGE here. Ownership doesn't inherit downward: an owner of a catalog does not own its schemas, and still needs explicit grants on child objects to access their data. What the owner gets automatically is the ability to manage all child objects, which is functionally like holding MANAGE on them.
MANAGE also has *reduced usage requirements*. You need a usage privilege only on the container levels strictly above the level where MANAGE is granted. You don't need one at that level or below it. On each of those higher levels, ownership or MANAGE satisfies the requirement as well as USE CATALOG or USE SCHEMA. The reduction covers only the metadata capabilities of MANAGE. Data access still goes through the normal usage gate.
| MANAGE granted on | Usage privileges needed to exercise it | Still needed to read data |
|---|---|---|
| Catalog | None | USE CATALOG, USE SCHEMA, SELECT |
| Schema | USE CATALOG on the parent catalog (or ownership or MANAGE on that catalog). USE SCHEMA is not needed. | USE CATALOG, USE SCHEMA, SELECT |
| Table, view, volume or function | USE CATALOG on the parent catalog and USE SCHEMA on the parent schema (or ownership or MANAGE on either parent) | USE CATALOG, USE SCHEMA, SELECT |
Checkpoint 2 of 5· Check yourself
A user holds MANAGE on the schema prod.finance and nothing else. They try to grant privileges on a table in that schema and the attempt fails. What is the most likely missing piece?
MANAGE on a schema is inherited by the schema's tables and does not need USE SCHEMA. It does need the usage privilege on the level above, which is the parent catalog.
“MANAGE on a schema requires USE CATALOG on the parent catalog (or ownership or MANAGE on that catalog), but not USE SCHEMA on the schema.”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
A data engineer named Priya has been granted `SELECT` directly on the table `finance.reporting.quarterly_revenue`, but nothing else. When she runs a query against that table, it fails with a permission error. Which additional privileges, taken together, must Priya hold before her query can succeed? (Select all that apply.)(Select 2)
Correct answers: A, B — `USE CATALOG` on the `finance` catalog, so she can traverse into the catalog that contains the target schema.; `USE SCHEMA` on the `reporting` schema, so she can traverse into the schema that contains the target table.
- A. Usage privileges act as prerequisites for traversal: without `USE CATALOG` on the containing catalog, Priya cannot reach any schema or table nested inside it, regardless of what she was granted directly on the table.
- B. The same traversal requirement applies one level down: `USE SCHEMA` on the containing schema is required before a direct table-level grant like `SELECT` can take effect.
- C. `MANAGE` controls the ability to grant and revoke privileges on an object; it has no bearing on whether an existing `SELECT` grant is honored, so it is not required here.
- D. Ownership of the containing schema is unrelated to whether a table-level `SELECT` grant works; ownership does not need to be held by the person who was separately granted read access.
- E. `CREATE TABLE` governs the ability to create new tables in a schema and has no effect on reading data from tables that already exist, so it does not resolve this failure.
- F. `READ METADATA` supports lightweight discovery of object metadata without full access; it is not one of the usage privileges required to traverse the catalog and schema hierarchy for a query.
Sources2
3.ALL PRIVILEGES and composite privileges at a container
ALL PRIVILEGES granted on a catalog implies all catalog-level privileges. Granted on a schema, it implies all schema-level privileges. Through inheritance that covers a lot. Unity Catalog does not record each privilege separately when the grant is made. ALL PRIVILEGES expands to all available privileges at the time permissions checks are made.
To avoid accidental data exfiltration or privilege escalation, ALL PRIVILEGES deliberately excludes four privileges: EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE and READ METADATA. A principal with ALL PRIVILEGES on a catalog therefore cannot manage grants in that catalog unless it also holds MANAGE or ownership.
Some privileges are *composite*, with *child* privileges that grant a subset of what the composite allows. MANAGE has the children READ METADATA and MANAGE ACCESS CONTROL. MODIFY has the children INSERT, UPDATE and DELETE (Beta). Composite and child privileges are granted and revoked independently. Revoking a composite privilege does not revoke a child privilege that was granted explicitly.
Checkpoint 4 of 5· Check yourself
A group has ALL PRIVILEGES on the catalog analytics. Which of these can it NOT do on the strength of that grant alone?
Granting privileges to others requires MANAGE, ownership, or ownership of a parent container. ALL PRIVILEGES excludes MANAGE.
“ALL PRIVILEGES does not include the EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE, or READ METADATA privileges.”Source: docs.databricks.com
4.Designing a privilege model around inheritance
Databricks' best-practice guidance tells you to use the downward inheritance of the hierarchy to build an effective privilege model. Its concrete recommendations follow from the mechanics covered above.
- Scope teams with schemas. It is typical to create a schema per team and grant USE SCHEMA and CREATE TABLE only to that team, along with USE CATALOG on the parent catalog. Everything the team creates in the schema then falls under one well-defined boundary.
- Give ownership to groups, and grant sparingly. The creator of an object is its first owner, so creators should reassign ownership to appropriate groups, especially for production objects. Be sparing with ownership, MANAGE and ALL PRIVILEGES, because grants on containers reach far.
Checkpoint 5 of 5· Match them up
Match each privilege to how it behaves in the hierarchy
Tap a term, then the definition that fits it.
Ownership does not inherit downward, although owners can manage child objects. MANAGE inherits with reduced usage requirements, metastore privileges do not inherit, and SELECT inherits from a schema to its tables and views.
“Ownership doesn't inherit downward in Unity Catalog.”Source: docs.databricks.com
Sources5
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.MANAGE on a catalog lets the holder read every table in it, because it needs no usage privileges.Why is that wrong?
The reduced usage requirement covers only the metadata and management capabilities of MANAGE. Reading or writing data still needs USE CATALOG, USE SCHEMA and the data privilege.
Covered in MANAGE: inherited management without full ownership
2.Because MANAGE does not include SELECT, a MANAGE holder can never obtain access to the data.Why is that wrong?
MANAGE doesn't grant data privileges itself, but a MANAGE holder can grant themselves data access privileges such as SELECT.
Covered in MANAGE: inherited management without full ownership
3.The owner of a catalog also owns every schema and table inside it.Why is that wrong?
Ownership doesn't inherit downward. A catalog owner can manage child objects but does not automatically own them.
Covered in Who can grant: ownership follows the hierarchy too
4.ALL PRIVILEGES on a catalog makes the grantee equivalent to its owner, including the ability to grant access to others.Why is that wrong?
ALL PRIVILEGES excludes MANAGE (as well as READ METADATA and the EXTERNAL USE privileges), so it does not let the grantee manage grants.
Covered in ALL PRIVILEGES and composite privileges at a container
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The owner of the catalog or schema that contains the object.”
↩︎ Who can grant: ownership follows the hierarchy too“A REVOKE statement succeeds even if the specified privileges were not granted in the first place.”
↩︎ Who can grant: ownership follows the hierarchy too - 2.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“When you own a container object, you automatically get the ability to manage all child objects, even if you don't own those children directly.”
↩︎ Who can grant: ownership follows the hierarchy too“Ownership doesn't inherit downward in Unity Catalog.”
↩︎ Who can grant: ownership follows the hierarchy too“If MANAGE is granted on a container object, the user also gets MANAGE on all child objects.”
↩︎ MANAGE: inherited management without full ownership“MANAGE on a catalog requires no usage privileges.”
↩︎ MANAGE: inherited management without full ownership“Users with MANAGE can grant themselves these privileges.”
↩︎ MANAGE: inherited management without full ownership“Because ownership doesn't inherit downward to child objects, owners still require explicit grants on those child objects.”
↩︎ MANAGE: inherited management without full ownership“Granting a composite privilege does not grant its child privileges”
↩︎ ALL PRIVILEGES and composite privileges at a container“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”
↩︎ Exam trap 1“users with MANAGE can explicitly grant themselves data access privileges such as SELECT.”
↩︎ Exam trap 2“if you own a catalog, you don't automatically own the child schemas within the catalog”
↩︎ Exam trap 3“ALL PRIVILEGES does not include the EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE, or READ METADATA privileges.”
↩︎ Exam trap 4“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”
↩︎ Prediction“MANAGE on a schema requires USE CATALOG on the parent catalog (or ownership or MANAGE on that catalog), but not USE SCHEMA on the schema.”
↩︎ Checkpoint“ALL PRIVILEGES does not include the EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE, or READ METADATA privileges.”
↩︎ Checkpoint“Ownership doesn't inherit downward in Unity Catalog.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/privileges-referenceOfficial docs
“View all owner-visible metadata for an object, including permissions, row filters, column masks, and ABAC policies”
↩︎ Who can grant: ownership follows the hierarchy too - 4.
“ALL PRIVILEGES expands to all available privileges at the time permissions checks are made.”
↩︎ ALL PRIVILEGES and composite privileges at a container - 5.
“Securable objects in Unity Catalog are hierarchical, and privileges are inherited downward.”
↩︎ Designing a privilege model around inheritance“Owners of parent catalogs and schemas also have the ability to grant privileges on all objects in the catalog or schema.”
↩︎ Checkpoint