MatthewCurlerTAC opened a new issue, #44903:
URL: https://github.com/apache/superset/issues/44903
### Bug description
After updating to a build that includes #40409 (`fix(sqllab): require
dataset match for raw query access`), a Gamma user with `sql_lab` and explicit
`schema_access` and `catalog_access` grants can no longer run queries in SQL
Lab. Every referenced table must now resolve to a registered dataset with
`datasource_access`.
The user can still browse the schema in the SQL Lab sidebar and view
existing charts and dashboards. Only query execution is denied.
Error shown in SQL Lab:
> You need access to the following tables: "default_catalog.db.table",
"all_database_access" or "all_datasource_access" permission
Query: `SELECT * FROM db.table LIMIT 100`
I understand from the PR description that this is intentional, however:
1. The error message doesn't tell the user why access was denied, it reads
as if the schema grants are missing. I spent significant time verifying that
the `ab_view_menu` / `ab_permission_view_role` entries were correct before
finding the PR.
2. There is no configuration option to restore the previous behavior. The
documented mitigations are `database_access` (too broad when a database has
multiple schemas) or registering and individually granting every table as a
dataset (untenable for many dozens of tables/views across multiple instances).
3. Per-table dataset grants don't scale for schemas where tables are added
and renamed frequently (here, a dbt-managed warehouse schema).
4. This suggests Superset must be the sole point of access control. We've
taken a different approach: managing access to database objects via the schema
and applying in-database RLS. #40409 significantly limits the flexibility of
the security model that can be applied.
I may one day be grateful for the flexibility this affords, but today it is
simply a major headache.
### How to reproduce the bug
1. Use a database whose engine supports catalogs (StarRocks, via
`starrocks://.../default_catalog.db`). "Allow changing catalogs" enabled.
2. Create a role (or use Gamma plus `sql_lab`) with only:
- `database_access`: none
- `catalog_access` on `[Database].[default_catalog]`
- `schema_access` on `[Database].[default_catalog].[db]`
3. Assign the role to a non-admin user and log in as them.
4. In SQL Lab, run `SELECT * FROM db.table LIMIT 100`.
### Expected results
The query runs, as it did before #40409, since the user holds
`schema_access` for the schema containing the table.
### Actual results
The query is denied with the error above, even though the permissions exist
and are attached to the user's role. I verified this in the metadata DB: view
menu names are exact matches and the role holds the corresponding
`schema_access` and `catalog_access` permissions.
### Screenshots/recordings
_No response_
### Superset version
master / latest-dev
### Python version
Not applicable
### Node version
Not applicable
### Browser
Not applicable
### Additional context
### Proposed resolution
Add a config option (e.g. `SQLLAB_REQUIRE_DATASET_MATCH`, default `True`)
that gives admins flexibility to restore the historical `schema_access` /
`catalog_access` permissions for SQL Lab.
I'm realize this reopens the gap #40409 closes, but an opt-in setting will
ensures this behavior must be explicitly enabled. For deployments that
deliberately grant schema-wide access, that is the intended behavior.
### Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to
my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug
report.
- [x] I have checked Superset's logs for errors and if I found a relevant
Python stacktrace, I included it here as text in the "additional context"
section.
--
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]
