Using the {OWNER} Principal¶

Access Resource policies in the Privacera portal can grant permissions to the resource owner by using {OWNER} as the user principal. For Databricks Unity Catalog (UC), PolicySync expands {OWNER} to the current owner of the resource (typically the UC owner email) and applies the matching grants in Unity Catalog.

Overview¶

Use {OWNER} when privileges should always follow the resource owner—for example, ensuring the owner always has Select or Use Catalog—without editing the policy each time ownership changes.

Databricks ownership behavior¶

Databricks Unity Catalog automatically grants native ownership privileges to the owner of each object. Ownership is hierarchical.

For example:

Catalog → Schema → Table

If the same user owns the catalog, schema, and table, that owner can typically work with the table using Databricks’ built-in ownership semantics—even without an Access Resource policy from the Privacera portal for those objects.

An Access Resource policy in the Privacera portal (including {OWNER}) is still useful when you need:

• Privileges that must follow ownership transfers (for example, Use Catalog on the parent catalog when a new schema owner does not already have it)
• Consistent grants across resources where owners differ at catalog, schema, or table level

Ownership transfer and parent privileges ({OWNER})¶

Native ownership on a child object does not always imply the privileges needed on parent objects.

Example¶

1. Owner1 creates a schema (and may own related objects).

2. Ownership of the schema is transferred to Owner2.

3. Owner2 does not have Use Catalog on the parent catalog.

4. Result: Owner2 cannot access the schema, even though they are the schema owner.

Fix with {OWNER}¶

Create a schema-level Access Resource policy that grants Use Catalog on the parent catalog to {OWNER}. That privilege is required so the schema owner can access the schema after ownership transfer.

After PolicySync applies the policy:

• The current schema owner (Owner2) receives Use Catalog on the parent catalog.
• If ownership later moves again, {OWNER} grants follow the new owner.

Prerequisites¶

Typical UC defaults:

1
2
3

ranger.policysync.connector.0.user.use.email.as.service.name=true
ranger.policysync.connector.0.user.email.case.conversion=none
ranger.policysync.connector.0.user.email.persist.case.sensitivity=true

Creating an Access Resource policy with {OWNER}¶

1. In the Privacera portal, create or edit an Access Resource policy for the Unity Catalog service.

2. Set the resource (catalog / schema / table / column as needed).

3. Under users, add {OWNER} (not a fixed email, unless you want a static grant).

4. Select permissions (for example, Select on a table, or a privilege such as Use Catalog that the owner needs on parent objects).

5. Select Save.

After you save, PolicySync processes the policy changelog and applies {OWNER} grants for the current resource owner. After an ownership change, resource sync reapplies those grants to the new owner. For timing and transfer behavior, see Ownership changes.

Example — table Select¶

• Table owner: owner@example.com
• Access Resource policy: user {OWNER}, permission Select
• Result: owner@example.com receives Select in UC

Example — schema owner needs parent catalog access¶

• Schema ownership transferred to Owner2 without Use Catalog
• Access Resource policy using {OWNER} so the schema owner also gets Use Catalog on the parent catalog
• Result: Owner2 can access the schema after sync

Ownership changes¶

When UC ownership changes:

• Before resource sync: The previous owner may still have access from the last applied grants. The new owner does not yet receive {OWNER} privileges from PolicySync.
• PolicySync detects the owner change on the next resource sync.
• After resource sync: {OWNER}-based grants move to the new owner, and the previous owner’s {OWNER} grants are removed.

No policy edit is required for privileges to follow the new owner. Until sync completes, access can briefly reflect the old ownership state.

Limitations¶

• Access Resource policies only (current): {OWNER} support described here is for Access Resource policies on Databricks Unity Catalog.
• Owner must be a managed Ranger user: The UC owner email must match a Ranger user that PolicySync manages. Databricks-only or unmanaged owners do not get {OWNER} grants.
• Email mismatch: UC owner email must match the managed Ranger user email (including case rules).
• Native ownership ≠ parent privileges: Owning a schema/table does not always grant Use Catalog on the parent catalog; use {OWNER} (or explicit grants) when parent access is required after transfer.

Best practices¶

• Keep UC owners as managed users with correct emails.
• Use {OWNER} for “always grant the current owner X,” especially after ownership transfers.
• For schema/table owners who may lack parent catalog privileges, add Access Resource policies that grant the needed parent privileges to {OWNER}.
• Align email case settings with UC and Ranger.
• After ownership or managed user changes, confirm PolicySync completed successfully.

Troubleshooting¶