jordanbecketmoore opened a new issue, #24742: URL: https://github.com/apache/airflow/issues/24742
### Apache Airflow version 2.3.2 (latest released) ### What happened I wrote a custom security manager that created custom roles for Airflow users based on LDAP mapping. These users would only be given permissions to view, edit, etc. DAGs whose access_control parameters explicitly permitted their role to view. However, it was discovered that if a malformed DAG file was added to the DAG_FOLDER, an import error would be thrown, but none of the users in custom roles would be able to view it in their web ui. A user with a default Viewer or greater role could see the error, however. Upon further investigation, I found that this occurs due to a filter that is applied [here](https://github.com/apache/airflow/blob/main/airflow/www/views.py#L895-L901=). If a DAG file is scanned for the first time and causes an import error to be thrown, two things happen that prevent the error from passing this filter and showing on the web ui to RBAC users: 1. The DAG is never added to the database. 2. The custom role is never given permissions to view the DAG. ### What you think should happen instead It is important for developers to be able to see the traceback of the errors thrown by their DAGs. One of two things needs to be changed - either the way in which import errors are handled is changed to allow these malformed DAGs to pass the filter (i.e. the DAG is added to the database and the appropriate roles are given the appropriate permissions), or the filter itself is changed to allow these import errors to be shown. The former option is, in my opinion, preferable, since it would also allow the web ui to list the DAG, allowing the users to view the code from there. Also, I can't think of a way to pull off the latter. ### How to reproduce - Create a custom role (custom_role) that does not have permission to view all DAGs and assign a user that role. In my case, this was done through a custom security manager, but it can also be accomplished through the web ui of an Admin user. - Write a DAG whose access_control dictionary specifies that custom_role may at least view it. Ensure that this DAG file is malformed in such a way that will cause Airflow to throw an import error when it attempt to parse it. - Add the DAG to the DAG_FOLDER and wait for Airflow to attempt to parse it. - A user with Viewer role or higher will be able to see the import error at the top of the web ui, but the user with custom_role only will not. ### Operating System Amazon Linux 2 ### Versions of Apache Airflow Providers _No response_ ### Deployment MWAA ### Deployment details Airflow is deployed on an AWS cluster, with its webserver and scheduler on EC2 instances using celery worker nodes on separate EC2s. ### Anything else I have been able to get around this with a custom security manager that overwrites the create_dag_specific_permissions function. The DagBag is loaded from the DAG_FOLDER instead of the database. Then the security manager iterates over the DagBag's import errors and checks to see if the DagBag contains a DAG whose fileloc is the same as that of the import error. If not, a new DAG object is created with the appropriate fileloc. Regex is used to parse the file to find the dag_id and access_control parameters to add to the new DAG. If the DAG is so malformed that it cannot find these parameters, the security manager generates a random string to serve as the dag_id and sets access_control to explicitly give all custom roles can_view permissions. This new "pseudoDAG" is then added to the DagBag. After all import errors are dealt with, the function is allowed to continue. This function is triggered when the cli command `airflow sync-perm --include-dags` is executed. ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md) -- 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]
