Pluggable AST(abstract syntax tree) rewrite to support 3rd party authorisation use cases

[raviann]

Terms AST - abstract syntax tree

Description Today one can provide custom authorisation by implementing io.prestosql.spi.security.SystemAccessControl in the plugin form. SystemAccessControl does support allow/deny kind of use-cases, which does not suffice for filter-masking and other use cases being required by 3rd party authorisation plugins

To support them, it would require AST rewrite, and today it is not pluggable either. We should make AST rewrite pluggable i.e io.prestosql.sql.rewrite.StatementRewrite.Rewrite to support the use-cases mentioned below

Use-cases

1. Support for filter, masking and decryption of columns


• Replacing Table node with inline aliased relation to support filter masking Ex: 
Input query: select id, quantity, amount from orders
 Modified query: select id, quantity, amount from (select id, mask(quantity), amount from orders where amount < 10000)orders

• Support for wrapping the columns in where predicate with appropriate decrypt user defined functions 
 Ex:
 Input query: select name, salary from accounts where salary> 10000; 
 Modified query: select name, decrypt(salary) from accounts where decrypt(salary)> 10000; 

• Custom use-cases like ensure the result set is valid, except that mask a sensitive field in the final output
 Ex: 
Input query: select name, age from employee where age < 40
 Modified query: select name, mask(age) from (select name, age from employee where id > 100 and location='US' and age > 30 )employee where age< 40



2. Logging of input query and the modified AST (in sql form) for audit purpose

[martint]

This falls under the umbrella of https://github.com/prestosql/presto/issues/18. Our plan is not to expose connectors to the AST, but to allow them to supply additional filters or projections base on authorization. There are multiple reasons why exposing the ASI to connectors is problematic:

• It requires the AST and any supporting infrastructure and its dependencies to be visible to plugin classloaders. This can cause class conflicts that we currently avoid by limiting the set of classes that are part of the SPI.
• There are a number of hard questions around how the SQL should be evaluated:
  • what's the "environment" under which it gets evaluated (path, catalog, schema, authorization identifier)?
  • what happens if the SQL has free variables? Do they get bound to the enclosing scope if possible? Or is it treated as an error? (this would require some complex changes to the analyzer)
    • what happens if the SQL has semantic errors (references to missing columns, type mismatch, missing functions, etc)? It might be hard/impossible to report a user-friendly error.