rusackas commented on code in PR #43499:
URL: https://github.com/apache/superset/pull/43499#discussion_r4289256113
##########
superset/models/sql_lab.py:
##########
@@ -602,6 +602,68 @@ def to_dict(self) -> dict[str, Any]:
"id": self.id,
}
+ @property
+ def name(self) -> str:
+ """
+ Expose ``label`` as ``name`` so callers that treat a ``SavedQuery`` as
+ a generic datasource (e.g. chart create/update commands) can rely on
+ a uniform ``name`` attribute across all datasource types.
+
+ ``label`` is a nullable column, so fall back to an id-based name
+ rather than returning ``None`` from a property typed as ``str``.
+ """
+ return self.label or f"Saved query {self.id}"
+
+ @property
+ def schema_perm(self) -> Optional[str]:
+ """
+ Schema-level permission string, mirroring ``Query.schema_perm``.
+
+ Required so that ``SecurityManager.raise_for_access(datasource=...)``
+ and the ``Slice`` ``before_insert``/``before_update`` listener (which
+ copies ``perm``/``catalog_perm``/``schema_perm`` onto the chart) can
+ treat a ``SavedQuery`` like any other datasource instead of raising
+ ``AttributeError``.
+ """
+ return security_manager.get_schema_perm(
+ self.database.database_name, self.catalog, self.schema
+ )
+
+ @property
+ def catalog_perm(self) -> Optional[str]:
+ """Catalog-level permission string; see ``schema_perm`` above."""
+ return security_manager.get_catalog_perm(
+ self.database.database_name, self.catalog
+ )
+
+ @property
+ def perm(self) -> str:
+ """Object-level permission string; see ``schema_perm`` above."""
+ return f"[{self.database.database_name}].[{self.name}](id:{self.id})"
Review Comment:
Fair, this PR does make saved_query rows reachable through that path for the
first time. Still think this needs a shared perm-namespace fix across
query/semantic_view/saved_query, not a patch to just this one spot, so I'd
rather track that as its own issue than block this PR on it.
##########
superset/commands/chart/utils.py:
##########
@@ -29,10 +29,17 @@
def validate_chart_datasource_type(datasource_type: str) -> None:
"""Accept persistent chart sources with names and type-aware access
policies.
- SQL Lab queries are registered datasource types but are not persistent
- chart sources; accepting all DatasourceDAO registrations would include
them.
+ A raw SQL Lab ``query`` is a registered datasource type but not a
+ persistent chart source, so it's excluded here; accepting all
+ DatasourceDAO registrations would include it. A ``saved_query`` is
+ explicitly persisted and named by the user, so it's accepted alongside
+ ``table``/``semantic_view``.
"""
- if datasource_type not in (DatasourceType.TABLE,
DatasourceType.SEMANTIC_VIEW):
+ if datasource_type not in (
+ DatasourceType.TABLE,
+ DatasourceType.SEMANTIC_VIEW,
+ DatasourceType.SAVEDQUERY,
Review Comment:
I get the concern, but I don't think a chart that can't execute yet should
also be blocked from being created. Export/import support feels like its own
follow-up, not a blocker here, same call as the ExploreMixin thread above. Fair
thing to flag either way.
##########
superset/commands/chart/utils.py:
##########
@@ -33,15 +33,22 @@
def validate_chart_datasource_type(datasource_type: str) -> None:
"""Accept persistent chart sources with names and type-aware access
policies.
- SQL Lab queries are registered datasource types but are not persistent
- chart sources; accepting all DatasourceDAO registrations would include
them.
+ A raw SQL Lab ``query`` is a registered datasource type but not a
+ persistent chart source, so it's excluded here; accepting all
+ DatasourceDAO registrations would include it. A ``saved_query`` is
+ explicitly persisted and named by the user, so it's accepted alongside
+ ``table``/``semantic_view``.
"""
if (
datasource_type == DatasourceType.SEMANTIC_VIEW
and not is_semantic_layers_enabled()
):
raise ValidationError(SemanticLayersDisabledError.message)
- if datasource_type not in (DatasourceType.TABLE,
DatasourceType.SEMANTIC_VIEW):
+ if datasource_type not in (
+ DatasourceType.TABLE,
+ DatasourceType.SEMANTIC_VIEW,
+ DatasourceType.SAVEDQUERY,
Review Comment:
This one's legit, but it's a visibility gap, not an access-escalation one: a
database-only grant just means these charts won't surface yet, not that the
wrong people can see them. Feels like a reasonable follow-up (mirroring
table_backed_slice_join for SavedQuery) rather than a blocker, happy to be told
otherwise.
##########
superset/models/sql_lab.py:
##########
@@ -602,6 +602,68 @@ def to_dict(self) -> dict[str, Any]:
"id": self.id,
}
+ @property
+ def name(self) -> str:
+ """
+ Expose ``label`` as ``name`` so callers that treat a ``SavedQuery`` as
+ a generic datasource (e.g. chart create/update commands) can rely on
+ a uniform ``name`` attribute across all datasource types.
+
+ ``label`` is a nullable column, so fall back to an id-based name
+ rather than returning ``None`` from a property typed as ``str``.
+ """
+ return self.label or f"Saved query {self.id}"
+
+ @property
+ def schema_perm(self) -> Optional[str]:
+ """
+ Schema-level permission string, mirroring ``Query.schema_perm``.
+
+ Required so that ``SecurityManager.raise_for_access(datasource=...)``
+ and the ``Slice`` ``before_insert``/``before_update`` listener (which
+ copies ``perm``/``catalog_perm``/``schema_perm`` onto the chart) can
+ treat a ``SavedQuery`` like any other datasource instead of raising
+ ``AttributeError``.
+ """
+ return security_manager.get_schema_perm(
+ self.database.database_name, self.catalog, self.schema
+ )
+
+ @property
+ def catalog_perm(self) -> Optional[str]:
+ """Catalog-level permission string; see ``schema_perm`` above."""
+ return security_manager.get_catalog_perm(
+ self.database.database_name, self.catalog
+ )
+
+ @property
+ def perm(self) -> str:
+ """Object-level permission string; see ``schema_perm`` above."""
+ return f"[{self.database.database_name}].[{self.name}](id:{self.id})"
+
+ @property
+ def data(self) -> ExplorableData:
+ """
+ Minimal explorable payload.
+
+ ``SecurityManager`` builds access-denied error messages (and a few
+ dashboard-RBAC lookups) off ``datasource.data["id"]``/``["name"]``
+ for *every* datasource type it can be asked to authorize, not just
+ ones that are actually explorable; without this a denied saved-query
+ chart request fails with ``AttributeError`` instead of the intended
+ 403.
+ """
+ result: ExplorableData = {
Review Comment:
This one worries me. Looks like a gap in GetExploreCommand itself, not
something saved_query introduces: whenever slc is set, _authorize_datasource
checks access to the chart, not the datasource form_data actually overrode.
It's only reachable for saved_query now because .data stopped throwing, but
table and semantic_view look exploitable the same way. I don't want to patch
this under #29697's scope without understanding what the live-dataset-switch
flow in Explore actually needs. Mind if we open a dedicated security issue for
it instead of blocking here?
--
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]
