Overriding can_access_datasource to block access to sensitive tables

[gabriel-korbato]

Superset's permissions are set up in a way that if a user has access to a data source, they have implicit access to the database. This makes sense in many cases, but my database has a set of tables that contain sensitive data that only privileged users should be able to access, make charts from, or see charts from. The list of tables with sensitive data is large and growing each day, so it is not practical to set row-level permissions, because this requires listing each table.

I started browsing the code for SupersetSecurityManager, since I had to make a subclass of that for other security matters, found the can_access_datasource function, and overrode it in superset_config.py with additional logic that checks the table name and the user's roles to determine if they should have access. I tested this with log statements and verified that the function correctly returns True or False as required: when an unprivileged user accesses a chart that has a datasource that should be privileged, the function returns False, and when a privileged user accesses the same chart, the function returns True.

So far so good, but I am stuck because Superset displays the chart fed from the datasource anyway. Does anyone know what I am missing?

[dosubot[bot]]

Hi @gabriel-korbato! I'm Dosu and I’m helping the superset team.

Overriding can_access_datasource is a good start, but Superset's permission model has several layers that can bypass your custom logic. If a user has the all_database_access or all_datasource_access permission, they get universal access to all databases and datasets, which overrides granular checks—even your custom can_access_datasource logic. Also, if dashboard RBAC is enabled or you're using embedded dashboards/guest tokens, dashboard access can implicitly grant access to all charts and their underlying datasets, regardless of dataset-level permissions. In these cases, unauthorized users may still see charts or get "Access Denied" overlays instead of being fully blocked (source, source).

To enforce restrictions, make sure roles do not have all_database_access, all_datasource_access, or explicit access to sensitive datasets. For dashboards, check that the frontend sends the correct dashboardId in chart requests—missing this can bypass permission checks and expose data from unauthorized tables (source). Fine-grained chart-level access is limited if multiple charts share the same datasource (source). There is an active proposal (SIP-126) to add explicit viewer permissions for dashboards and charts, but it's not implemented yet.

If you need strict per-dataset or per-chart visibility, you may need to add custom filtering logic or handle unauthorized chart hiding on the frontend for now.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[gabriel-korbato]

@dosu I could try your suggestion to create and use a role that does not have all_database_access or all_datasource_access, but that would require explicitly giving permissions to each new and future datasources. In my use case users generally require to create datasources, charts and dashboards, and to share them amongs themselves. Also, new data will be added to the database daily. It wouldn't be practical to keep up with this having to explicitly grant permissions each time, so by default I am giving Alpha permissions to users, and then using the custom logic to prohibit access to only certain tables in the database (and any datasources that query it). Is there a way to generally grant access to all data sources, but to prohibit a role from accessing specific tables or charts based on those tables?

To give more detail, my plan was to have two database connections to the database, one with a privileged user and another with an unprivileged user. Only privileges Superset accounts would have access to the connection with the privileged user. The problem is that if those privileged users make a datasource and chart from a sensitive table and share it, I need a way to block unprivileged users from seeing those datasources and charts. This is why I set to customize can_access_datasource. What other part of the code must be modified to make these exceptions work?

[dosubot[bot]]

Superset doesn't have a built-in way to generally grant access to all datasources while blacklisting specific tables or charts for certain roles. The permission model is designed around granting access, not denying it, so you have to explicitly manage permissions for each datasource if you want to avoid global access—there's no native "deny" or blacklist mechanism that scales automatically as new datasources are created (discussion, discussion).

Overriding can_access_datasource is the right extension point for custom logic, but Superset enforces access through several layers: raise_for_access is called throughout the backend for datasources, charts, and dashboards, and it checks for broad permissions like all_database_access and all_datasource_access, as well as ownership, schema, and dashboard RBAC (source). If users have these global permissions (as with the Alpha role), your custom logic in can_access_datasource will be bypassed.

If you want to block access to specific tables or charts, you must remove these global permissions from user roles and manage access at the datasource level. This does mean you'll need to grant permissions for new datasources as they're created. There is no built-in automation for this, but you can script permission assignments or use backend hooks to help.

Recent changes have introduced field-level permission middleware for multi-tenant setups, including dataset field restrictions by schema and table name (PR #35877). If you are on a recent version, you may be able to leverage this for more granular control, but it still requires explicit configuration.

The dual-connection approach (privileged/unprivileged) doesn't natively solve the problem of restricting chart/datasource visibility—if a privileged user creates a datasource from a sensitive table and shares it, unprivileged users can still see it if they have broad permissions. You'd need to enforce your blacklist logic everywhere access is checked, which is essentially what raise_for_access and can_access_datasource do.

In summary: to enforce exceptions for sensitive tables or charts, you must (1) remove global access permissions from user roles, (2) manage datasource permissions explicitly, and (3) extend your custom logic in both can_access_datasource and, if needed, raise_for_access. There is no built-in scalable blacklist mechanism, but recent field-level permission features may help if you are able to configure them for your use case.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}