[FEATURE REQUEST] Add Row Level and Column Level access control.

[silwalanish]

Is your feature request related to a problem? Please describe.

Is there a way to define row/column level access control through the RBAC defined here?

Describe the solution you'd like

With row level access control, I would like to filter certain rows from result set for a given Role.
With column level access control, I would like to add data masking to certain columns for a given Role.

Describe alternatives you've considered

No response

Additional context

No response

[shohamyamin]

I think that the catalog should return when a resource is requested the row filter expression and the column mask expression that way the Trino/spark will be able to force the row filter/column mask.

the catalog itself cannot make the filter/masking because he isn’t the one that access to the object storage and do the compute

[snazy]

RLAC/CLAC is IMO a very useful functionality/feature to restrict access to sensitive information to trusted client (e.g. query engines). Masking/hiding is technically probably the more straght-forward part, but getting "trust" right is tricky.

A table (or view referencing such a table directly or indirectly) that has CLAC/RLAC enabled, must not be accessible to untrusted clients, simply because once you give those access, they technically see everything. Or the catalog would have to intercept (and rewrite) manifest-lists, manifest-files and data/delete files according to the user's privileges and R/CLAC rules (masking) - that's quite expensive.

However, if you have an engine/client that you really trust to securely apply the CLAC/RLAC filters, the catalog can grant access to it and rely on the engine/client to do the right thing.

"Trust" itself has very different meanings for different people. Some say they're fine with running queries only on that engine X, Y or Z. Others say that the engine must run on extremely locked down hardware, ensuring that malicious users must not even be able to use side-channel attacks to get (some) knowledge of the protected data.

Don't get me wrong, definitely don't wanna shoot this down or so - it's the opposite. Just saying, that there's a lot of work to do.