Re: [I] DAG-level access control broken without global RESOURCE_DAG permissions [airflow]

2026-01-29 Thread via GitHub


potiuk commented on issue #58985:
URL: https://github.com/apache/airflow/issues/58985#issuecomment-3817899335

   > :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.


-- 
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]



Re: [I] DAG-level access control broken without global RESOURCE_DAG permissions [airflow]

2026-01-29 Thread via GitHub


potiuk closed issue #58985: DAG-level access control broken without global 
RESOURCE_DAG permissions
URL: https://github.com/apache/airflow/issues/58985


-- 
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]



Re: [I] DAG-level access control broken without global RESOURCE_DAG permissions [airflow]

2026-01-15 Thread via GitHub


vincbeck commented on issue #58985:
URL: https://github.com/apache/airflow/issues/58985#issuecomment-3756342483

   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.


-- 
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]



Re: [I] DAG-level access control broken without global RESOURCE_DAG permissions [airflow]

2025-12-06 Thread via GitHub


Arunodoy18 commented on issue #58985:
URL: https://github.com/apache/airflow/issues/58985#issuecomment-3619826310

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


-- 
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]