Hi All, I'm replying with the same suggestion I made in GH just to revive this thread.
My preference is towards NOT exposing details about the authZ denial to the client, but returns a random ID which could be correlated (by a Polaris Admin) to the full details in a log message. WDYT? Cheers, Dmitri. On Sun, Jun 14, 2026 at 2:50 PM Prithvi S <[email protected]> wrote: > Hi all, > > I'm opening this discussion as suggested by @dimas-b in the review of PR > #4406 (https://github.com/apache/polaris/pull/4406), which touches > authorization behavior. > > Background: > Today, `PolarisAuthorizerImpl.authorizeOrThrow` produces a generic denial > message: > > Principal 'alice' with activated PrincipalRoles '[reader]' and activated > grants via '[]' is not authorized for op CREATE_TABLE_DIRECT > > This gives operators no indication of *which* privilege is missing or on > *which* entity, forcing them to grep the codebase to figure out the right > grant to add. > > What PR #4406 does: > It enriches the 403 message to include the missing privilege and target > entity, e.g.: > > ...is not authorized for op CREATE_TABLE_DIRECT; missing TABLE_CREATE on > NAMESPACE 'ns1' > > The legacy prefix is preserved verbatim so existing log scrapers continue > to work. This is a diagnostic-only change — authorization decisions > (allow/deny) are unchanged. > > Concern raised: > @dimas-b and @flyrain raised a valid security concern: returning AuthZ > details in the client-facing 403 response could expose information that a > malicious client might use to probe the permission model. > > The alternative suggested was to log the missing privilege details > server-side and surface only a correlation/trace ID in the client response, > allowing Polaris admins to correlate the client error to the server log > without leaking grant structure to untrusted clients. > > questions I have: > 1. Is the security concern significant enough to block enriching the > client-facing 403 message, or does the operator convenience justify it > (e.g., given that the privilege/entity names are not secret in most > deployments)? > 2. Should we pursue the log + correlation-ID approach instead? If so, is > there an existing logging/tracing infrastructure in Polaris we should hook > into? > 3. Are there precedents in other Iceberg catalog implementations for how > AuthZ denial details are surfaced? > > Happy to update the PR in whichever direction the community prefers. > > Regards, > Prithvi S >
