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 > >
