12.2 Ownership, Inheritance & Access Control Patterns

In Databricks Unity Catalog, managing security efficiently at scale requires a clear understanding of object ownership, hierarchical privilege inheritance, and enterprise access control patterns. While individual privilege grants (GRANT SELECT ON TABLE) work for small projects, enterprise data governance relies on cascading permissions down the 3-level namespace and isolating environments across catalogs. This section details how ownership operates, how privilege inheritance flows, and how to implement production-grade governance architectures.

The Unity Catalog Ownership Model

Every securable object in Unity Catalog—whether a metastore, catalog, schema, table, view, volume, or function—has exactly one principal designated as its owner. Ownership represents the ultimate administrative authority over that specific object.

Key Rules of Object Ownership

1. Default Creator Ownership: By default, when a user or service principal creates an object (e.g., executing CREATE TABLE), that creating principal automatically becomes the initial owner of the object.
2. Automatic Owner Capabilities: The owner of an object possesses implied ALL PRIVILEGES on that object. Owners can modify table schema (ALTER), delete data (DELETE/TRUNCATE), drop the object entirely (DROP), and grant or revoke privileges on that object to other principals (GRANT/REVOKE).
3. Exclusive Permission Management: Only the object owner, the owner of a parent container (e.g., schema owner), or a Metastore Admin can grant or revoke privileges on a securable object. Non-owner users cannot delegate access to others even if they hold SELECT or MODIFY.
4. Transferring Ownership: Ownership can be transferred to another principal using the ANSI SQL ALTER ... OWNER TO command:

-- Transferring table ownership to a functional group
ALTER TABLE production_catalog.finance_schema.quarterly_revenue 
OWNER TO `group_finance_engineers`;

-- Transferring schema ownership
ALTER SCHEMA production_catalog.finance_schema 
OWNER TO `group_finance_leads`;

Critical Best Practice: Databricks strongly recommends assigning object ownership to account-level groups or Service Principals rather than individual human user accounts. If an individual employee leaves the company and their user account is deactivated, any objects owned by that individual become orphaned, causing administrative locks and pipeline failures.

---

Hierarchical Privilege Inheritance

Unity Catalog implements hierarchical privilege inheritance, meaning that permissions granted at a higher level in the 3-level namespace automatically cascade down to all child objects contained within that namespace.

Metastore (Top Level)
  └── Catalog (e.g., main_catalog) --> Grant USE CATALOG, SELECT here
        └── Schema (e.g., sales_db) --> Cascades SELECT to all tables/views
              ├── Table 1 (orders)  --> Automatically inherits SELECT
              ├── Table 2 (line_items) --> Automatically inherits SELECT
              └── View 1 (daily_summary) --> Automatically inherits SELECT

Inheritance Cascade Rules

• Catalog-Level Grants: Granting SELECT on a catalog automatically grants SELECT on all existing schemas, tables, and views within that catalog, as well as any schemas and tables created in that catalog in the future.
• Schema-Level Grants: Granting SELECT on a schema automatically grants SELECT on all current and future tables and views inside that schema.
• Inherited vs. Explicit Grants: Privileges inherited from a parent container are non-blocking and cumulative. If a user has SELECT via schema inheritance, adding an explicit GRANT SELECT ON TABLE is redundant.
• Non-Revocability at Child Level: An inherited privilege cannot be revoked at the child level. For example, if group_analysts has SELECT granted on schema_finance, executing REVOKE SELECT ON TABLE schema_finance.payroll FROM GROUP group_analysts; will fail or have no effect. To restrict access to payroll, access must be granted at the individual table level rather than the schema level, or managed via row/column security policies.

---

Production Access Control Design Patterns

Enterprise Databricks deployments organize Unity Catalog namespaces to achieve strict environmental isolation and least-privilege administrative boundaries.

---

Comparative Matrix: Ownership vs Grants

---

Real-World Exam Scenarios & Edge Cases

Scenario 1: Managing Schema-Level Inheritance Restrictions

Problem: The data security team grants GRANT SELECT ON SCHEMA prod.marketing TO GROUP analysts;. Later, a sensitive table prod.marketing.customer_surveys is created. The admin attempts REVOKE SELECT ON TABLE prod.marketing.customer_surveys FROM GROUP analysts;, but analysts can still query the table.
Root Cause: Inherited permissions at the schema level override table-level revokes.
Solution: Revoke SELECT from GROUP analysts at the schema level (REVOKE SELECT ON SCHEMA prod.marketing FROM GROUP analysts;), and grant SELECT individually on non-sensitive tables.

Scenario 2: Preventing Orphaned Production Assets

Problem: A senior data engineer builds 50 tables in prod_catalog under their personal user identity alex@company.com. When Alex leaves the company, HR disables the account, preventing remaining engineers from altering or granting access to the tables.
Solution: Reassign ownership to a production group immediately:
ALTER TABLE prod_catalog.sales.orders OWNER TO group_data_engineers; or reassign all assets using Metastore Admin capabilities.

---

Summary Checklist for Exam Readiness

• Object owners have implied full control, including DDL, dropping, and granting access.
• Always use account-level groups for object ownership to avoid orphaned assets.
• Schema and catalog level grants cascade down to all existing and future child objects.
• Inherited grants cannot be revoked at the child level—you must manage grants at the appropriate container level.