> A clarification to this - the dag parser today is likely not protection against a dedicated malicious DAG author, but it does protect against casual DB access attempts - the db session is blanked out in the parsing process , as are the env var configs https://github.com/apache/airflow/blob/main/task-sdk/src/airflow/sdk/execution_time/supervisor.py#L274-L316 - is this perfect no? but it’s much more than no protection Oh absolutely.. This is exactly what we discussed back then in March I think - and the way we decided to go for 3.0 with full knowledge it's not protecting against all threats.
On Fri, Jul 25, 2025 at 8:22 AM Ash Berlin-Taylor <a...@apache.org> wrote: > A clarification to this - the dag parser today is likely not protection > against a dedicated malicious DAG author, but it does protect against > casual DB access attempts - the db session is blanked out in the parsing > process , as are the env var configs > https://github.com/apache/airflow/blob/main/task-sdk/src/airflow/sdk/execution_time/supervisor.py#L274-L316 > - is this perfect no? but it’s much more than no protection > > > On 24 Jul 2025, at 21:56, Jarek Potiuk <ja...@potiuk.com> wrote: > > > > Currently in the DagFile processor there is no built-in protection > against > > user code from Dag Parsing to - for example - read database > > credentials from airflow configuration and use them to talk to DB > directly. >
