suhail-zemoso commented on issue #54175:
URL: https://github.com/apache/airflow/issues/54175#issuecomment-3209289339
@adrian-edbert @potiuk
As I already shared in the error screenshot, from my understanding this
seems to be the expected behavior. We have created two different users: worker
and run_as_user.
I am running Airflow using the worker user (e.g., sudo -u worker airflow
standalone). I then created a DAG file and tried running a task using
run_as_user. Since the task runs under the run_as_user, it attempts to create
the _locks directory under the worker directory path, which results in a
permission error. To me, this looks like the expected behavior.
Note:
In the airflow.cfg file for both users, the following configs are present:
dag_bundle_storage_path = /home/worker/airflow/dag_bundles
dag bundle config list = `[ { "name": "git-bundle-test", "classpath":
"airflow.providers.git.bundles.git.GitDagBundle", "kwargs": { "subdir": "dags",
"tracking_ref": "main", "git_conn_id": "my_git_conn", "refresh_interval": 0 } }
] `
Could you please confirm if I am missing something here? Or, could you
kindly clarify the exact issue from your end so that I can better understand it?
So is it a valid bug?
From a
Linux/permission standpoint → ✅ this is expected behavior, not a bug.
From an Airflow design standpoint → ⚠️ it is a bug/issue, because tasks
shouldn’t need to touch worker-owned lock files at all. The design conflates
worker user duties with task user duties.
it’s expected that run_as_user cannot access worker-owned files. The reason
it’s reported as an “issue” is because Airflow’s implementation forces
run_as_user into that situation, which is not how impersonation should ideally
work.
--
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: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
