feat: use per-user db role for query exec (ENG-2474) #48
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries.
9656e5f to
bc1e229
Compare
a46c1d5 to
f5f217b
Compare
johnsca
commented
Aug 14, 2023
Comment on lines
413
to
416
| @listens_for(BaseQuery, "before_compile", retval=True) | ||
| def prefilter_query_results(query): | ||
| for desc in query.column_descriptions: | ||
| if desc['type'] is QueryResult: |
There was a problem hiding this comment.
This approach was the best I could come up with. It does ensure that the user only sees the QueryResult records that they "own" but doesn't actually use the role / RLS policy on that table because I couldn't figure out a way to actually wrap the query in a set / reset role, since there is no corresponding "after" event for queries. I'm open to suggestions on how to make it actually use the role, but it's worth noting that the RLS policy on the redash.query_results table is still important to prevent the user from issuing queries directly against that table to see results that they shouldn't.
There was a problem hiding this comment.
Can we add a comment in the code to this affect?
howbazaar
approved these changes
Aug 16, 2023
Comment on lines
413
to
416
| @listens_for(BaseQuery, "before_compile", retval=True) | ||
| def prefilter_query_results(query): | ||
| for desc in query.column_descriptions: | ||
| if desc['type'] is QueryResult: |
There was a problem hiding this comment.
Can we add a comment in the code to this affect?
thisisshi
pushed a commit
that referenced
this pull request
Mar 1, 2024
* feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 22, 2025
* feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 22, 2025
* feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 22, 2025
* feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 22, 2025
…8) (#47) If the current user has a `db_role`, they should only see query results that they have generated, so that they don't see results which contain info about resources they don't have permission to view. feat: use per-user db role for query exec (ENG-2474) (#48) * feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 22, 2025
…8) (#47) If the current user has a `db_role`, they should only see query results that they have generated, so that they don't see results which contain info about resources they don't have permission to view. feat: use per-user db role for query exec (ENG-2474) (#48) * feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 22, 2025
…8) (#47) If the current user has a `db_role`, they should only see query results that they have generated, so that they don't see results which contain info about resources they don't have permission to view. feat: use per-user db role for query exec (ENG-2474) (#48) * feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
May 28, 2025
…8) (#47) If the current user has a `db_role`, they should only see query results that they have generated, so that they don't see results which contain info about resources they don't have permission to view. feat: use per-user db role for query exec (ENG-2474) (#48) * feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
wgrant
pushed a commit
that referenced
this pull request
Jul 1, 2025
…8) (#47) If the current user has a `db_role`, they should only see query results that they have generated, so that they don't see results which contain info about resources they don't have permission to view. feat: use per-user db role for query exec (ENG-2474) (#48) * feat: use per-user db role for query exec (ENG-2474) Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. * Reject login from unknown SSO users * Use pre-filtered query for QueryResults rather than session-level `set role` * Add docstring with non-obvious context
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Login with per-user PG database role, if available, to ensure that RLS policies are applied to user queries. Also changes how the
redash.query_resultstable is filtered, since setting the role for the entire session broke saving queries (and probably some other things) due to the rest of the entire request session losing access to all of the other Redash tables.Depends on: https://github.com/stacklet/platform/pull/1732
Tested on my sandbox with my non-admin SSO user and manually injected account mappings. Confirmed that the user could only get query results from the
resourcestable that they had an account mapping for, and that they could neither see query results generated by other users, nor directly query theredash.query_resultstable and see anything other than their own records.