mistercrunch commented on issue #29171: URL: https://github.com/apache/superset/issues/29171#issuecomment-2542082484
Some comments here, first I think the main topic here, given that we do have the permission model and logic to support dataset restrictions in Explore/Dashboard, is something more like "enforcing physical dataset-level access in SQL Lab". Currently - and I don't know if it's well documented today - SQL Lab data access-level policy is limited to "Database connection", meaning that if you have access to the db AND have SQL Lab access, you can run whatever queries you want. We may need to clarify this in the docs. Now, enforcing the rules we have around schema AND dataset-level access in SQL Lab is tricky because it requires parsing table/view names out of SQL Lab user-defined SQL, and checking against the perms. Note that we do have methods that are pretty well tested in the codebase to do that, but anything that relies on parsing SQL (in this case to extract "relations" (ie views and tables) names and sometimes guessing their schema) is a potential security risk. Today it'd be fairly easy to add something that extracts the relations name and checks against schema-level and relations-level perms in SQL Lab, but it's not impossible someone could find a way to work around that. Maybe with obfuscated SQL, or through some database-specific UDTFs-like constructs. Now, given that it'd be possible to build something that works but isn't bulletproof, my recommendation would be to put this behind a feature flag, call it "DANGEROUS_ENFORCE_DATA_ACCESS_POLICY_IN_SQL_LAB", with the proper disclaimer, something like ``` # This feature flag tries to enforce schema-level and physical-dataset access defined for Explore/Dashboard in SQL LAB # this is done by parsing the user-defined SQL and extracting/infereing schema and table/view names out of that SQL using # sqlglot/sqlparse. While this should just work in most cases, it may be possible to use this as an attack vector # using some SQL trickery. For instance if a user has DDL access, they could run a CREATE VIEW in a schema # they have full access to against another schema they don't have access to to bypass the policies in place DANGEROUS__ENFORCE_DATA_ACCESS_POLICY_IN_SQL_LAB: False, ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
