prestodb/presto · error · AccessDeniedException

Full data access is restricted by row filters and column mas

Error message

Full data access is restricted by row filters and column masks for table: 

What it means

RewriteWriterTarget validates that a table targeted by a distributed-procedure rewrite (e.g. CALL system.sync_partition_metadata-style rewrite of a writer target) is fully accessible. If any row filters (fine-grained access control) apply to the base table, it throws AccessDeniedException: full data access is required to rewrite the target safely, and filtered rows could corrupt the rewrite semantics.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/sql/planner/optimizations/RewriteWriterTarget.java:200

            return planChanged;
        }

        private void checkFullDataAccessControl(TableHandle tableHandle)
        {
            TableMetadata tableMetadata = metadata.getTableMetadata(session, tableHandle);
            QualifiedObjectName baseTable = new QualifiedObjectName(tableMetadata.getConnectorId().getCatalogName(),
                    tableMetadata.getTable().getSchemaName(), tableMetadata.getTable().getTableName());
            String errorMessage = "Full data access is restricted by row filters and column masks for table: " + baseTable;

            // Check for row filters on this target table
            List<ViewExpression> rowFilters = accessControl.getRowFilters(
                    session.getRequiredTransactionId(),
                    session.getIdentity(),
                    session.getAccessControlContext(),
                    baseTable);

            if (!rowFilters.isEmpty()) {
                throw new AccessDeniedException(errorMessage);
            }

            // Check for column masks on this target table
            Map<String, ColumnHandle> columnHandles = metadata.getColumnHandles(session, tableHandle);
            List<ColumnMetadata> columnsMetadata = columnHandles.values().stream()
                    .map(handle -> metadata.getColumnMetadata(session, tableHandle, handle))
                    .collect(toImmutableList());

            Map<ColumnMetadata, ViewExpression> columnMasks = accessControl.getColumnMasks(
                    session.getRequiredTransactionId(),
                    session.getIdentity(),
                    session.getAccessControlContext(),
                    baseTable,
                    columnsMetadata);

            if (!columnMasks.isEmpty()) {
                throw new AccessDeniedException(errorMessage);
            }

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Run the procedure as an identity exempt from row filters on the table (admin/service account with full access).
  2. Temporarily adjust the row-level security policy for the target table, run the rewrite, then restore it.
  3. Skip the rewrite for tables protected by row filters and manage them outside restricted access control.

Example fix

-- before
CALL system.sync_partitions('schema', 'table'); -- fails under row filter
-- after: run as user without row filters on 'table', or relax the policy first
ALTER POLICY table_filter ... ; -- temporarily exempt the operator identity
Defensive patterns

Strategy: try-catch

Validate before calling

-- before running the rewrite procedure, check row filters on the target
SELECT * FROM system.security.table_row_filters WHERE schema_name = ? AND table_name = ?;

Try / catch

try {
    execute("CALL system.sync_partitions('schema','table')");
} catch (AccessDeniedException e) {
    if (e.getMessage().startsWith("Full data access is restricted by row filters")) {
        // rerun under an identity exempt from row filters
        executeAs(adminIdentity, "CALL system.sync_partitions('schema','table')");
    } else throw e;
}

Prevention

When it happens

Trigger: Executing a distributed procedure / writer-target rewrite while the session's identity has row filters defined on the target table via the system access control; checkFullDataAccessControl finds non-empty rowFilters and denies access.

Common situations: Environments with fine-grained access control (row-level security policies) where an operator runs maintenance CALL procedures; service accounts that intentionally lack full table access attempting rewrites.

Related errors


AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/637dcbca00a28c17. Report an issue: GitHub.