22.8. Trino Data Store Security

The GeoMesa Trino store supports Data Security. Authorizations are enforced as an injected WHERE clause, based on the user’s access.

22.8.1. Trino-Layer Enforcement for Direct-SQL Consumers

Direct Trino consumers are filtered separately by the spatial plugin’s connector access control, configured as catalog properties in Trino (not data store parameters):

Catalog property	Required	Description
geomesa.security.auth-resolver	no	file (default) or a fully-qualified AuthorizationResolver class for an external lookup
geomesa.security.auth-mapping-file	with file	Path to a properties file mapping user.<n> / group.<n> → comma-delimited auth tokens
geomesa.security.auths-secret	no	Shared secret that clients must present in order to access the catalog

Setting either property opts the catalog into Trino-layer enforcement.

Visibility enforcement preserves the access control configured through iceberg.security, including authorization checks and column masks. Its visibility filter is applied alongside any existing row filters.

The file resolver reloads its mapping when the file’s modification time changes. If the file is missing or cannot be read or parsed, previously loaded authorizations are cleared and users receive empty authorization sets. Failed reads are retried on subsequent lookups, so access can recover when the file is readable again.

Warning

Only the spatial_iceberg catalog is protected — do not expose a plain iceberg catalog over the same tables to untrusted users.

22.8.2. Visibility-Column File Pruning

When Trino-layer enforcement is configured (see above), the spatial_iceberg connector can additionally use Iceberg per-file manifest statistics to skip whole data files that cannot contain any row the querying user is authorized to see. This is a performance optimization only: it runs alongside standard visibility filtering. It is opt-in, and controlled by these catalog properties:

Catalog property	Required	Description
geomesa.security.enable-visibility-expression-pruning	no	Master switch for visibility-column file pruning (default false). When unset or false, no pruning is attempted and behavior is identical to enforcement without this feature. Requires geomesa.security.auth-resolver to be configured.
geomesa.security.visibility-expressions	no	Comma-separated list declaring every distinct non-null visibility value the visibility column can hold (e.g. basic,basic&privileged). Enables the expression-pruning tier; when omitted, only the empty-authorizations tier is active.

The feature has two tiers:

• Empty-authorizations tier — active whenever pruning is enabled. A user with no authorizations can satisfy no visibility expression, so the only rows they can ever see are the unrestricted ones (NULL or empty '' visibility). Files that hold no such unrestricted rows are therefore pruned. This tier is sound for any visibility grammar and needs no configuration.

• Expression tier — active when geomesa.security.visibility-expressions is non-empty. Each declared value is evaluated through the same is_visible() decision the row filter uses, so files whose visibility values are not admissible for the user are pruned. This tier correctly handles compound (& / |) visibility expressions.

Warning

geomesa.security.visibility-expressions must be complete — it must list every distinct non-null visibility value that actually occurs in the data. A value that occurs in the data but is omitted from the list causes files holding only that value to be pruned, so a user whose authorizations would admit that value silently loses those rows (a correctness / availability issue). This is never a security leak — the is_visible() row filter still enforces confidentiality — but under-declaring prunes too much. Over-declaring is harmless: a declared value that never occurs simply never matches. When in doubt, declare more, not fewer.

The list is catalog-wide; for a catalog whose tables use different visibility values, declare the union of all of them.

22.8.3. Visibility Filtering in the Scan

The Scan connector reports the following visibility filtering metrics:

Metric	Meaning
Visibility bypassed rows	Rows returned without exact visibility filtering, using file statistics or a footer proof.
Visibility checked rows	Logical rows considered by the exact visibility filter.
Visibility rejected rows	Checked rows rejected by the exact visibility filter.
Visibility bypassed splits	Splits that bypass exact visibility filtering using file statistics or a footer proof.
Visibility filtered splits	Splits requiring exact visibility filtering; excludes splits pruned by a footer proof.
Visibility fallback value evaluations	Visibility decisions after reusing results within dictionary and run-length encoded blocks.
Visibility footer bypassed rows	Bypassed rows justified by a footer proof; included in Visibility bypassed rows.
Visibility footer bypassed splits	Splits with a footer proof that all rows are visible; included in Visibility bypassed splits.
Visibility footer pruned splits	Splits with a footer proof that no rows are visible, skipped before creating the data reader.
Visibility footer missing splits	Probed splits whose Parquet footer has no visibility summary.
Visibility footer invalid splits	Probed splits whose footer metadata fails validation.
Visibility footer unavailable splits	Splits whose footer probe fails, leaving the normal reader to read the file or report an error.
Visibility footer unproven splits	Splits with a valid summary that proves neither all rows nor no rows are visible.

Missing, invalid, unavailable, and unproven summaries retain exact row filtering. Splits that bypass using file statistics or do not attempt a footer probe do not increment footer outcome metrics. Visibility filtering optimizations are more likely to take effect if records with the same visibility are grouped together during writes.

GeoMesa-written Parquet files can also carry a file-wide visibility rollup in the custom geomesa.visibility.rollup footer entry. This extends bypass to mixed files: the reader evaluates an allOf expression against every absorbed authorization context, and bypasses only when all decisions succeed. An anyOf expression can prove that no row is visible: failure for any one absorbed context skips the split before creating its data reader. When neither proof applies, exact row filtering remains mandatory. Users with an empty authorization set, whether supplied through extra credentials or configured user mappings, can still read rows with NULL or empty visibility. Restricted rows remain hidden from those users.

GeoMesa’s filesystem compact command recomputes these summaries for each replacement file, after applying positional deletes.

22.8.4. Views

Views are supported under Trino-layer enforcement, but they shift where auth enforcement happens, which carries important requirements that an administrator must consider. A view is resolved through the connector’s view metadata and its body is expanded into base-table scans; the view relation itself is not a table and carries no __vis__ column of its own. The connector therefore treats a view as follows:

• If the view projects a __vis__ column through to its output, that column is filtered on the querying user’s auth tokens, exactly as it would be for a table.

• If it does not, the view relation is left unfiltered and enforcement falls entirely to the scans its body expands to — which delegates enforcement to the underlying catalog.

22.8.4.1. Auths applied when querying a view

Trino views default to DEFINER security, meaning the base tables are read as the view creator/owner. Under row-visibility enforcement the injected WHERE clause would be built from the owner’s auth tokens, and any user permitted to query the view would see the owner’s filtered rows — possible auth escalation/spillage.

To prevent that, views in the spatial_iceberg catalog are rewritten to run as the invoker, so every base-table scan resolves the auth tokens of the user actually running the query. This is on by default and is controlled by geomesa.security.use-invoker-auths (see View authorizations).

Warning

The rewrite applies only to views defined in the spatial_iceberg catalog, which is geomesa-trino’s enforcement point.

22.8.4.2. Views over other connectors

The spatial_iceberg access control can only filter rows in its own iceberg catalog. It has no ability to filter a table read from another catalog via a view defined in spatial_iceberg. Creating any view that joins, unions, or otherwise reads a non-spatial_iceberg table (i.e. via PostGIS, PostgreSQL, Hive) will return rows unfiltered by this connector, no matter how the geomesa.security.* properties are set.

This creates an implicit requirement: Once row-visibility enforcement is enabled on spatial_iceberg, any catalog reachable through a view must enforce its own row-level visibility filtering, resolved for the same querying user. For example, a trino connector pointing at PostGIS must be configured (and PostGIS configured) to ensure visibility filtering (see Data Security). A catalog that does not enforce visibility filtering must not be attached to a view on the spatial_iceberg connector that is intended to perform visibility filtering.