geido opened a new pull request, #45266:
URL: https://github.com/apache/superset/pull/45266
### SUMMARY
Follow-up hardening to #40409 (`fix(sqllab): require dataset match for raw
query access`).
That change made the raw-SQL paths (SQL Lab execute, MetaDB, and the MCP
`execute_sql` tool) authorize each referenced table against a **registered
dataset the user can access**, bypassing the historical
`catalog_access`/`schema_access` fallthroughs. But the per-table check in
`raise_for_access` still accepts the table if the user is an **editor
(owner)**
of a matching dataset:
```python
if self.can_access("datasource_access", datasource_.perm or "") or
self.is_editor(datasource_):
```
Editorship is self-service for anyone who can create datasets: creating a
dataset makes the creator its editor (`populate_subjects(...,
default_to_user=True)`),
and physical-dataset creation authorizes with the non-strict
`raise_for_access`, so schema-level data access is enough to create one. The
dataset is matched to a table **by name**, and a virtual dataset
(`SELECT 1 AS x`) named after a real table matches too.
The result is that editorship substitutes for data access on the raw-row
path:
a principal can read rows from a warehouse table through raw SQL (SQL Lab /
MCP
`execute_sql`) even though they hold no database, catalog, schema, or
datasource grant for it — and that access **survives revocation** of every
real
grant, while every other surface (`list_databases`, dataset read, chart data)
correctly denies them.
The editorship accept is the intended dataset-owner *"explore your own
dataset"* behavior from #20382, which belongs to the non-strict callers
(chart-data, dataset CRUD, `/table_metadata/`, `/select_star/`). It should
not
extend to returning raw rows from the underlying table.
**Fix:** restrict the editorship accept in the per-table loop to the
non-strict
path. Under `force_dataset_match=True`, a referenced table must resolve to a
registered dataset the user has `datasource_access` on. `#20382` behavior is
unchanged everywhere else.
```python
) or (not force_dataset_match and self.is_editor(datasource_)):
```
### BEFORE/AFTER
Verified on vanilla Apache Superset (this branch's base, `master`), SQLite
metadata DB, default `SupersetSecurityManager`, no downstream code — driving
the real REST endpoints and the real MCP `execute_sql` tool. The principal
is a
custom role (Gamma + `can_write` on `Dataset` + the `sql_lab` role) holding
only schema-level data access, then having it revoked.
| Scenario | Before | After |
|---|---|---|
| Schema-only user creates a physical dataset for a denied table, reruns SQL
Lab / MCP | **rows returned** | denied |
| After all data access revoked — SQL Lab (keeps another grant on the DB) |
**rows returned** | denied |
| After all data access revoked — MCP `execute_sql`, `force_refresh` |
**rows returned** | denied |
| User made editor by an admin, never had any data access — MCP | **rows
returned** | denied |
| No data access at all → virtual dataset named after a table → MCP | **rows
returned** | denied |
| One unrelated grant → virtual dataset named after a table → SQL Lab |
**rows returned** | denied |
| Control: table with a dataset the user *does* have `datasource_access` on
| allowed | allowed (unchanged) |
### TESTING INSTRUCTIONS
- `pytest tests/unit_tests/security/manager_test.py -k
editorship_denied_in_strict_mode`
- `pytest tests/integration_tests/security_tests.py -k
"force_dataset_match_denies_editor_only or non_strict_allows_editor"`
New coverage asserts that editorship alone is denied under
`force_dataset_match=True` while still authorizing access without it (the
`#20382` owner-explore grant), alongside the existing `#40409` dataset-match
tests.
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
This changes an authorization boundary: a role that previously ran SQL Lab or
MCP queries against a table **solely** by virtue of editing a same-named
dataset will now need explicit `datasource_access` on the dataset. See the
`UPDATING.md` note.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
