Issue with DAG Visibility and Access Control in Airflow 3.0.2

[carlos54]

Apache Airflow version

3.0.2

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

3.0.2

What happened?

In Airflow 3.0.2, we are encountering an issue where users are unable to view only their own DAGs without receiving a 403 error on the DAG listing screen. To avoid this error, the permission "can read on DAGs" must be enabled. However, enabling this permission causes the user to see all DAGs, not just the ones they are authorized to access.

What you think should happen instead?

Expected Behavior: Users should only see DAGs for which they have explicit permissions (e.g., can_read on specific DAGs), without needing global can read on DAGs permission that exposes all DAGs.

Actual Behavior: Without can read on DAGs, users get a 403 error on the DAG listing page. With it, they see all DAGs, violating the intended access control.

Request: Please advise if this is a known issue or if there is a recommended workaround to restrict DAG visibility per user while avoiding the 403 error.

How to reproduce

We tested this with a custom role that includes the following permissions:

[can read on My Profile, can read on DAG Runs, menu access on DAG Dependencies, can read on DAG Code, can read on Website, can read on Jobs, menu access on Jobs, can read on Task Instances, menu access on Task Instances, can read on DAG:sandbox1_dags_01, can edit on DAG:sandbox1_dags_01, can read on View Menus, can create on DAG Runs, menu access on DAG Runs, can read on SLA Misses, menu access on SLA Misses, menu access on DAGs, menu access on Datasets, can read on ImportError, menu access on Actions, can create on Task Instances, can read on Task Reschedules, menu access on Task Reschedules, can edit on DAG Runs, can delete on DAG Runs, can edit on Task Instances, can delete on Task Instances, menu access on Documentation, menu access on Docs, can read on DAG Dependencies, menu access on DAG Run:sandbox1_dags_01, can read on DAG Warnings, can read on Task Logs, can read on XComs]
and the acces control on the DAG :

access_control={
    'sandbox1': {'can_read', 'can_edit', 'menu_access'}
}

Operating System

debian

Versions of Apache Airflow Providers

Native package only :

apache-airflow 3.0.2
apache-airflow-core 3.0.2
apache-airflow-providers-amazon 9.8.0
apache-airflow-providers-celery 3.11.0
apache-airflow-providers-cncf-kubernetes 10.5.0
apache-airflow-providers-common-compat 1.7.0
apache-airflow-providers-common-io 1.6.0
apache-airflow-providers-common-messaging 1.0.2
apache-airflow-providers-common-sql 1.27.1
apache-airflow-providers-docker 4.4.0
apache-airflow-providers-elasticsearch 6.3.0
apache-airflow-providers-fab 2.2.0
apache-airflow-providers-ftp 3.13.0
apache-airflow-providers-git 0.0.2
apache-airflow-providers-google 15.1.0
apache-airflow-providers-grpc 3.8.0
apache-airflow-providers-hashicorp 4.2.0
apache-airflow-providers-http 5.3.0
apache-airflow-providers-microsoft-azure 12.4.0
apache-airflow-providers-mysql 6.3.0
apache-airflow-providers-odbc 4.10.0
apache-airflow-providers-openlineage 2.3.0
apache-airflow-providers-postgres 6.2.0
apache-airflow-providers-redis 4.1.0
apache-airflow-providers-sendgrid 4.1.0
apache-airflow-providers-sftp 5.3.0
apache-airflow-providers-slack 9.1.0
apache-airflow-providers-smtp 2.1.0
apache-airflow-providers-snowflake 6.3.1
apache-airflow-providers-ssh 4.1.0
apache-airflow-providers-standard 1.2.0
apache-airflow-task-sdk 1.0.2

Deployment

Official Apache Airflow Helm Chart

Deployment details

No response

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

[potiuk]

@vincbeck -> that looks like FAB Auth Manager issue ?

[vincbeck]

Correct, but I think it should be fixed by #51462. Waiting to be released

[vikramkoka]

@vincbeck is this resolved now?

[potiuk]

I think we can close it preliminary and ask @carlos54 to confirm (or signal if we need to re-open) the updated Fab provider has been released in 2.2.0 so it could be tested there. And anyhow it was not 3.0.2 (de-facto) bit provider issue

[vincbeck]

Correct, it should be resolved :)