You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Alexandre Dutra <ad...@apache.org> on 2026/04/19 18:37:07 UTC
[DISCUSS] PolarisPrivilege fields and grant validation
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
Re: [DISCUSS] PolarisPrivilege fields and grant validation
Posted by Michael Collado <co...@gmail.com>.
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 <ad...@apache.org> 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é <jb...@nanthrax.net>
> 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 <ad...@apache.org>
> 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
> > >
>
Re: [DISCUSS] PolarisPrivilege fields and grant validation
Posted by Alexandre Dutra <ad...@apache.org>.
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é <jb...@nanthrax.net> 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 <ad...@apache.org> 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
> >
Re: [DISCUSS] PolarisPrivilege fields and grant validation
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <ad...@apache.org> 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
>
Re: [DISCUSS] PolarisPrivilege fields and grant validation
Posted by Michael Collado <co...@gmail.com>.
Strengthening assertions at grant time seems like a good approach to me. As
Alex notes, most of the incorrect grants become noise and are ineffectual
at authz.
Backward compatibility is something to consider, though I think that the
fact that we might allow certain grants today that have no impact on actual
authz gives us more room to just fix things.
Mike
On Thu, Apr 23, 2026 at 10:28 AM Yufei Gu <fl...@gmail.com> wrote:
> Hi Alex, thanks for raising this, I agree the issues are valid and worth
> addressing.
>
> +1 on enforcing semantic correctness at grant time. Without validation,
> it’s easy to end up with inconsistent or meaningless grant records. With
> proper validation, fields like securableType, securableSubTypes, and
> granteeType would no longer be “dead” metadata, but instead help define and
> enforce the semantics of privilege grants. That said, we should be
> thoughtful about backward compatibility. It would be great to get more
> input from the community.
>
> Yufei
>
>
> On Mon, Apr 20, 2026 at 10:18 AM Dmitri Bourlatchkov <di...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > Thanks for your diligent review! I think your points are quite valid and
> > certainly worth fixing.
> >
> > Regarding the practical code changes, I'm personally a bit hesitant to
> just
> > start altering that code right away.
> >
> > I'd appreciate getting feedback on this from Dennis and Michael.
> >
> > Cheers,
> > Dmitri.
> >
> > On Sun, Apr 19, 2026 at 2:37 PM Alexandre Dutra <ad...@apache.org>
> 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
> > >
> >
>
Re: [DISCUSS] PolarisPrivilege fields and grant validation
Posted by Yufei Gu <fl...@gmail.com>.
Hi Alex, thanks for raising this, I agree the issues are valid and worth
addressing.
+1 on enforcing semantic correctness at grant time. Without validation,
it’s easy to end up with inconsistent or meaningless grant records. With
proper validation, fields like securableType, securableSubTypes, and
granteeType would no longer be “dead” metadata, but instead help define and
enforce the semantics of privilege grants. That said, we should be
thoughtful about backward compatibility. It would be great to get more
input from the community.
Yufei
On Mon, Apr 20, 2026 at 10:18 AM Dmitri Bourlatchkov <di...@apache.org>
wrote:
> Hi Alex,
>
> Thanks for your diligent review! I think your points are quite valid and
> certainly worth fixing.
>
> Regarding the practical code changes, I'm personally a bit hesitant to just
> start altering that code right away.
>
> I'd appreciate getting feedback on this from Dennis and Michael.
>
> Cheers,
> Dmitri.
>
> On Sun, Apr 19, 2026 at 2:37 PM Alexandre Dutra <ad...@apache.org> 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
> >
>
Re: [DISCUSS] PolarisPrivilege fields and grant validation
Posted by Dmitri Bourlatchkov <di...@apache.org>.
Hi Alex,
Thanks for your diligent review! I think your points are quite valid and
certainly worth fixing.
Regarding the practical code changes, I'm personally a bit hesitant to just
start altering that code right away.
I'd appreciate getting feedback on this from Dennis and Michael.
Cheers,
Dmitri.
On Sun, Apr 19, 2026 at 2:37 PM Alexandre Dutra <ad...@apache.org> 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
>