DAG-level access control broken without global RESOURCE_DAG permissions

[bmoon4]

Apache Airflow Provider(s)

fab

Versions of Apache Airflow Providers

Description

When implementing team-based DAG isolation by removing global RESOURCE_DAG permission, users cannot access DAG runs, or task instances—even with explicit scoped permissions via access_control.

This forces users to grant global permissions as a workaround, defeating the purpose of DAG-level access control.

Current Behavior

Without global permissions: (RESOURCE_DAG)

• ✅ DAG list page (/dag) returns scoped dags (access_control) - thanks to this fix Fix: allow users with specific DAG permissions to access DAGs when no pecific DAG is requested #51462
• ❌ DAG runs not visible
• ❌ Task instances not visible
• Even with explicit access_control permissions for dagrun

With global permissions (workaround):

• ✅ All views accessible (DAG Run, Task Instances)
• ⚠️ But users see ALL DAGs (no isolation)

Expected Behavior

Users should be able to access their scoped DAGs, runs, and tasks using only the permissions defined in access_control, without needing global permissions.

Environment

• Airflow Version: 3.0.6
• FAB Provider Version: apache-airflow-providers-fab == 2.4.1
• Backend: Any (issue is in auth logic)

Steps to Reproduce

1. Create a DAG with scoped access:

dag = DAG(
    "team_a_dag",
    access_control={"TEAM_A": {'can_read', 'can_edit'}}
)

2. Create a user with only TEAM_A role (no global RESOURCE_DAG permission)

3. Try to view DAG runs (/dag_runs), Task Instances(/task_instances)
   Result: 403 Forbidden ❌

Root Cause Analysis

Four authorization issues in fab_auth_manager.py:

1. get_authorized_dag_ids() ignores DAG Run: scoped permissions
2. is_authorized_dag() requires DAG-level permission before checking sub-entities
3. _is_authorized_dag() returns false for list endpoints without checking any scoped permissions
4. _is_authorized_dag_run() doesn't check DAG-level permission as fallback

Related Issues

Similar issue mentioned by @romanpanov993 in #51325

Apache Airflow version

3.0.6

Operating System

debian

Deployment

Other Docker-based deployment

Deployment details

No response

What happened

No response

What you think should happen instead

No response

How to reproduce

1. Create a DAG with scoped access:

dag = DAG(
    "team_a_dag",
    access_control={"TEAM_A": {'can_read', 'can_edit'}}
)

2. Create a user with only TEAM_A role (no global RESOURCE_DAG permission)

3. Try to view DAG runs (/dag_runs), Task Instances(/task_instances)
   Result: 403 Forbidden ❌

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

[Arunodoy18]

Hi, I think i got the issue ,it will be a good issue to solve . .take-issue .
ThankYou.

[vincbeck]

I am not sure this is a bug but something intended. But we can definitely change it. Several things about it:

• access_control is deprecated and I would not recommend using it. Authorization are now delegated to auth managers so having FAB style permissions defined in your DAG is not recommended. This parameter (access_control) would only work if you use FAB auth manager, if someday you switch to another auth manager, all your permissions defined in your DAGs will be dismissed
• Why this behavior? When access_control is defined in your DAG, we give the defined action (e.g. can_read) to the defined role (e.g. TEAM_A) access to Dags in general. But that's it. We do not give permissions to underlying resources such as dag runs, task instances, xcoms etc. Since access_control has no way to define whether a Dag author wants to also give permissions to these underlying resources we have 2 options:
  • We either keep it that way
  • We give permissions to all the underlying Dag resources

What do you think? Pinging @potiuk here as well to get his insights.

[potiuk]

    :param access_control: a dict where each key is a role name and each value can be:
        - a set() of DAGs resource action names (e.g. `{'can_read'}`)
       - or a dict where each key is a resource name ('DAGs' or 'DAG Runs') and each value
        is a set() of action names (e.g., `{'DAG Runs': {'can_create'}, 'DAGs': {'can_read'}}`)

You can already add permissions for DAG runs like described above - so clearly it has been foreseen that you need to explicitly add "DAG Runs" as accessible this way). It is deprecated indeed, so I am not sure if we want to implement any changes there, but maybe - if you also want "Task Instances" to be added @bmoon4 -> feel free to open PR, or if you do not feel like it, create a feature request.