UI - "Runs" and "Task Instances" submenus in the "Dags" Menu only work with "Can Read on Dags" permission

[devgonvarun]

Apache Airflow version

3.0.3

Related issue: #51299

If "Other Airflow 2 version" selected, which one?

No response

What happened?

Case: Custom airflow role with access to some dags.

The "Runs" and "Task Instances" submenus in the "Dags" Menu only work with "Can Read on Dags" permission which gives permission to read on all dags not just some dags. For example: when only using "can read on DAG:dag1" permission for example, the "Runs" and "Task Instances" submenus have a 403 error.

"can read on Task Instances", "menu access on Task Instances", "can read on DAG Runs", "menu access on DAG Runs" work fine when going through a selected dag.

What you think should happen instead?

"Runs" and "Task Instances" should list the runs and task instances for the dags the logged in user's roles have access for.

How to reproduce

Create a new airflow user with access to only some dags:
remove "can read on DAGs" permission and instead add "can read on DAG:X" permission where dag_id=X for your newly created role.

Then using this new role, navigate to the "Runs" and "Task Instances" submenus in the "Dags" Menu screen as shown in the screenshots above.

Operating System

Debian GNU/Linux 12 (bookworm)

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

Helm Chart v 1.18.0

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[vikramkoka]

@pierrejeambrun Can you please respond when you have a moment?
The 403 seems odd

[potiuk]

I think it's possibly somewhere between @pierrejeambrun @vincbeck and FabAuthManager :). Not sure which one exactly :D

[vincbeck]

I see. I think this is a bug. The pages "list dag runs" and "list task instances" in the dags list page are not specific to a Dag. Their intent is to list all Dag runs (or task instances) across all dags. That's why we are checking whether the user has access to access all dags. But instead, we should check whether the user has access to at least one dag. I'll work on it

[pierrejeambrun]

Yes that is not normal, it's a bug. Thanks Vincent for working on this one.

[vincbeck]

While working on this issue I am wondering something. Let's take the "list dags" example. When the user lists dags, we check whether the user has permissions to list dags. To do that, we actually check whether the user has access to at least one dag with auth_manager.get_authorized_dag_ids(user=user, method=method) > 0. If they do have access to at least one dag, then the list of authorized dags is returned to the user. To return the list of authorized dags to the user, Airflow uses the same function used to figure whether the user had access to list dags: auth_manager.get_authorized_dag_ids(user=user, method=method). I am wondering if it actually makes sense to check whether the user is authorized to list dags because the API returns only the dags the user has access to anyway. What if we remove the authz check on list dags API? The consequence would be, instead of having a 403, the user would get an empty list of DAGs. In a way, in a fined grained access context, it makes more sense. Let's say I am user who has access to the Dag test only but this Dag does not exist (or has been removed) in the Airflow environment. In the current implementation, if I list Dags, I'll get a 403, but does it make sense? I have permissions to access Dags, I just happen to not have access to Dags existing in the environment.

Sorry for this message a bit philosophical. What do you think?

[pierrejeambrun]

Yes we could update all 'LIST' endpoints of the API and instead return an empty list if there is no DAG permission. Also it's probably smarter because, if you start adding some filters to your query, you might end up with 0 results => "There is no dag that you have access to that also respect the filters applied" and this will yield an empty list today, which shouldn't be really different from when there is no filter applied.

From the code perspective though, I don't know how to achieve that because I would love for it to remain consistent. (all endpoints beside LIST will need a dependency on has_access to something, and if we remove it for LIST it might be hard to understand for other contributors why it's required in other endpoint and not for lists, also that could bring copy/past issue easily)

[vincbeck]

From the code perspective though, I don't know how to achieve that because I would love for it to remain consistent. (all endpoints beside LIST will need a dependency on has_access to something, and if we remove it for LIST it might be hard to understand for other contributors why it's required in other endpoint and not for lists, also that could bring copy/past issue easily)

Maybe a comment explaining why would suffice?