set the channel topic: Design doc: https://docs.google.com/document/d/1Q_PgVN2WpKfAyagBzwPTU1KXV3tp1kuVfGRH4J6F8xk/edit?tab=t.0

Folks, starting this channel to streamline the review process for row/col level RBAC. On a side-note, I saw two Slack accounts for some folks and added both, feel free to remove the account that is irrelevant.

@Ankit Sultana @Yupeng Fu I have added comments to address your questions, can you please check? Also, can you take a look at the new auth response and the query rewriters, the proposed approach to implement RLS? Thanks!

Hey @Prashant Pandey, Thanks for the contribution! I think you have addressed most of my questions, but I wanted to discuss one of them in the channel to close it out quickly: It seems we are storing the row-level filter in query options. Is this an internal detail, as in we are doing this to prevent adding a new parameter to PinotQuery and other classes? Or, would SQL queries now allow configuring row level filters via SET statements?

*Addendum: I suppose this is only for the third feature (Dynamic Row Filtering), and RLS would apply filters automatically. But I am not sure what's the exact use-case for allowing query options to be used for configuring row-level filters (outside of debugging).

@Ankit Sultana Basically as what Neha said, we need to basically get this value from somewhere. Query option, http header, auth token metadata, etc. Doing this basically helps us achieve tenant level isolation easily. Consider the case wherein we have a table with 1000s of merchants, and we want a tenant to be able to see only its own rows. If we go with the current RBAC impl, we'd basically have to create one policy for each of these merchants. The policy might look like:

{
  "policyId": "'policy-doc-merchant000'",
  "rowFilter": "'merchantId' = 'merchant000'"
}

What's being proposed is we rather just create a single policy for a merchant role that looks like this:

{
  "policyId": "'policy-doc-any-merchant'",
  "rowFilter": "'merchantId' = $merchantId"
}

If we can get the value of

$merchantId

from somewhere, we can essentially resolve this filter and apply the row filter dynamically to the query. This is much easier. Now where we get this value from, it can be anywhere. In fact, we can have a lookup hierarchy - 1st: Query options 2nd: HTTP Header 3rd: auth token metadata.

Another use-case is a filter like this:`WHERE tsInMillis > now() - 86400000` . We'll have to resolve this too.

I see.. that makes sense. I think query options can introduce a vulnerability of their own wherein if an endpoint is prone to sql injection, a hacker may try to inject the query option to access data for other merchants. Maybe it's a minor issue since platform owners should ideally ensure that users are not allowed to set the corresponding query option in their SQL. Idk. I don't have a strong opinion here. Having a query option would make it easier to debug issues so I am kinda on the fence

one option is to add a hook so that the platform owner can enforce where the value is picked up from. It should NOT be part of SQL text such as SET etc.

Another thought is that there should be a simple ACL store in OSS (maybe a config file similar to the current table auth ?) which has the lookup data (username -> values)

@Ankit Sultana @Yupeng Fu I have added a section on enhancing basic auth configs for RLS/CLS, which was missing earlier. Can you please take a look?