Hello everyone,

We use unity catalog, separating our dev, test and prod data into individual catalogs.

We run weekly vacuums on our prod catalog using a service principal that only has (read+write) access to this production catalog, but no access to our dev/test catalogs. I'd like to keep it this way if possible.

For testing, we do shallow clones from these production tables to the test catalog, using a separate service principal that has (read-only) access to the prod catalog, as well as (read+write) access to the test catalog.

However, when we do such a shallow clone on a (managed) table in Databricks Runtime 13.3, our production service principal cannot run vacuum on the *source table* anymore:

com.databricks.sql.managedcatalog.acl.UnauthorizedAccessException: PERMISSION_DENIED: User does not have USE CATALOG on Catalog 'test-catalog'

This is very unexpected. It seems like the service principal needs access to the clone to be able to vacuum the original table. The other way around makes sense, but it doesn't make sense that I need access to the cloned tables to vacuum the original. Right now, it is possible to disturb our production job just by cloning the table somewhere else.

Is this a bug? Is there any workaround?

Cheers, Peter