Wrong user impersonated to HMS when querying a view with definer security in Trino >= 371

[Laonel]

With Hive metastore impersonation enabled, when querying a view from Hive catalog with security definer, when this view is defined on a Hive table, both the view and the table metadata will be retrieved from the metastore using the invoker identity. This will cause query failures if HMS has authorization enabled and the invoker has access to the view but not to the table.

To support this we would have to create a new Hive metastore using the session that's impersonating the view definer to retrieve table metadata.

I am creating this to start a discussion whether this is something we would like to support in Trino.

[lukasz-walkiewicz]

cc @findepi @electrum

[findepi]

@Laonel would you be able to verify what was the Hive connector behavior in Trino 370 with regards to the problem you're describing?

(In 371 we merged #9482 that changed mechanics around metastore impersonation)

[Laonel]

Thanks @findepi, I tested on Trino 370 and indeed view definer identity is correctly passed to metastore when analyzing the query (in newer version this fails on analysis). However, this case still doesn't work as the invoker session is always used during query execution (stored in QueryStateMachine I believe). For reference, for view CREATE VIEW hive_view AS SELECT FROM hive_table query such as SELECT * FROM hive_view fails on call to metadata.getTableSchema if the invoker has no permissions to read hive_table metadata in HMS.

For this to work Trino would have to support data source impersonation, which I know can get complex. I was thinking if it would be possible to modify ConnectorSession SPI to allow connectors to access impersonation information - keeping the default behavior, but allowing individual connectors to implement impersonation.

[findepi]

on Trino 370 and indeed view definer identity is correctly passed to metastore when analyzing the query (in newer version this fails on analysis)

so we have a regression, let me mark the issue as a bug then.
can you please also verify 371 is the first version that exhibits this behavior?

cc @dain @kokosing @lukasz-walkiewicz

However, this case still doesn't work as the invoker session is always used during query execution

Yes, that's a known limitation.
I think @kokosing @Praveen2112 were recently thinking how to address that.

For this to work Trino would have to support data source impersonation, which I know can get complex

We have been discussing this internally at Starburst. There was no evidence that it would be complex.

SPI to allow connectors to access impersonation information - keeping the default behavior, but allowing individual connectors to implement impersonation.

I think that this might be possible already today, without any SPI modifications.
Please take a look at @Praveen2112 's #15197

[Laonel]

can you please also verify 371 is the first version that exhibits this behavior?

Confirmed, starting from 371 it fails during analyze.

I think that this might be possible already today, without any SPI modifications.

Thanks for the link. It is implemented for JDBC-based connectors now, so to make it work with Hive would require finding a way to capture authorization in Hive connectors.