Hello Sebastien, I'd say it's quite feasible for this purpose by having Calcite push-down pre-processed queries to Druid and being a kind of a "front" to underlying Druid DB.
Regarding rejecting queries other than SELECT: 1) Parse the query and get the SqlNode representing the root of the syntax tree. 2) Extend SqlShuttle <https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/util/SqlShuttle.html> to check & manipulate the syntax tree, returning null for rejected nodes & recursively iterating for SELECT sub-queries. Note that you can use SqlSelect's getFrom, getGroup, etc to get all of the possible nodes which can contain subqueries. Also note that SqlSelect itself is a subtype of SqlCall. Regarding "tenant_id" in WHERE case, I'm not too sure as I'm neither familiar with Druid nor with Druid adapter in Calcite. Regardless, it should be doable on the adapter level AFAIK. Hope that was helpful! Regards, Askar Bozcan On Sun, 2 Apr 2023 at 18:07, Sebastien Rosset <[email protected]> wrote: > Would it make sense to use Apache Calcite as a security mediator? Has > calcite already been used for that purpose? The mediator would parse > untrusted SQL queries, reject queries other than SELECT (including any > sub-queries), and inject multi-tenancy WHERE filters in every SELECT query, > including sub-queries? > > More specifically, consider a Druid database which is configured to > implement multi-tenancy with shared datasources: > > https://druid.apache.org/docs/latest/querying/multitenancy.html#partitioning-shared-datasources > . > Every Druid datasource would have a "tenant_id" attribute that can be used > in a Druid-SQL WHERE clause. > > Thank you. Sebastien >
