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
