We could introduce a concept of "lineage" to privilege targets - e.g., TABLE_READ_DATA could have TABLE_LIKE-lineage for the target entity, which would include the table's entire hierarchy.
If we are granting CATALOG_MANAGE_ACCESS directly to Principal Roles, I think that was probably an oversight. It should be that all catalog privileges should be assigned to catalog roles and only catalog roles should be assigned to principal roles. It might be worth sketching out a diagram of what privileges should be grantable to what roles and for what target entities. Mike On Mon, Apr 27, 2026 at 10:18 AM Alexandre Dutra <[email protected]> wrote: > Hi all, > > We can try to clean up PolarisPrivilege, but the devil is in the > details: for instance, we'll need more than one securable type per > privilege to account for the hierarchy of securables: catalog > > namespace > table-like | policy. > > Furthermore, because the management API provides minimal detail > regarding privilege validity, the tests have turned into the practical > source of truth. These tests exhibit specific opinionated patterns, > such as: > > - Granting certain privileges (e.g., SERVICE_MANAGE_ACCESS) on ROOT > directly to principal roles. > - Assigning other privileges, like CATALOG_MANAGE_ACCESS, to principal > and catalog roles without clear distinction. > - etc. > > So, the full cleanup may take some time and require some discussions. > I'll take a stab at that. > > Thanks, > Alex > > > > On Mon, Apr 27, 2026 at 2:15 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > > Hi all, > > > > Enforcement at grant time makes sense to me. > > > > I also agree that we should clean up PolarisPrivilege. We might want to > > consider a "deprecation path," such as including warning log messages, to > > avoid any backward compatibility issues. > > > > Regards, > > JB > > > > On Sun, Apr 19, 2026 at 8:37 PM Alexandre Dutra <[email protected]> > wrote: > > > > > Hi all, > > > > > > I found a few issues with PolarisPrivilege that I'd like to raise for > > > discussion. > > > > > > 1. Unused or incorrect metadata > > > > > > PolarisPrivilege has 3 unused fields: securableType, > > > securableSubTypes, and granteeType. They are effectively dead metadata > > > today. > > > > > > Moreover, the two-argument constructor PolarisPrivilege(code, > > > securableType) defaults granteeType to CATALOG_ROLE. This is wrong for > > > ROOT-level privileges: SERVICE_MANAGE_ACCESS, CATALOG_CREATE, > > > CATALOG_LIST, PRINCIPAL_CREATE, PRINCIPAL_LIST, PRINCIPAL_ROLE_CREATE, > > > and PRINCIPAL_ROLE_LIST all have securableType=ROOT but are silently > > > marked as granteeType=CATALOG_ROLE. > > > > > > 2. No validation at grant time > > > > > > Nothing in the metastore API or its implementations validates that a > > > grant is semantically meaningful. The only check today is > > > grantee.getType().isGrantee() in some impls. > > > > > > This means, for example: > > > > > > - You can grant TABLE_READ_DATA on a PRINCIPAL entity (mismatched > > > securable type). > > > - You can grant VIEW_DROP on an ICEBERG_TABLE entity (mismatched > > > securable sub-type). > > > - You can grant any privilege to a PRINCIPAL directly (grantee type > > > violation). > > > - You can grant a privilege on a PRINCIPAL_ROLE to itself (self-grant). > > > - You can grant a privilege on a securable in catalog A to a > > > CATALOG_ROLE in catalog B (cross-catalog grants). > > > > > > Such grant records become pure noise once written. Some impls filter > > > them out, some others don't. > > > > > > So, here are a few questions to the community: > > > > > > 1. Should we clean up / fix PolarisPrivilege? > > > 2. Should we enforce semantic meaningfulness when writing grants? And > how? > > > > > > Thanks, > > > Alex > > > >
