Applied permissions to self._error_file

[kevinbsilva]

As explained at the issue #15946 the Web UI does not show the log for tasks that failed when the owner of the DAG is not airflow or the DAG is being executed by another user (run_as_user parameter). When airflow is dumping the error to the temporary file, it opens the file for writing and raises a Permission Denied error, since it's created with restricted permissions. Any default user cannot write into the file, only read.

The NamedTemporaryFile created at the base_task_runner creates the file with the umask 600 and that module does not allow to pass custom permissions when creating the object.

To avoid this problem, i've added a os.chmod after creating the NamedTemporaryFile at the base_task_runner module. After that, no Permission Denied is thrown when a task fails and the log is accessible through the Web UI.

No major changes were made, only the chmod being applied solved the problem.

Closes #15946

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (flake8, pylint and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it’s a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[uranusjr]

Setting the execution bit looks extremely wrong to me. At the very least this should be 0o644 instead, but even that I’m not sure is the correct fix. Why does this only affect failed tasks? There are many unanswered questions between the issue report and the fix here.

[potiuk]

Agree with @uranusjr . I believe this is quite wrong approach. The right solution should be setting the Umask properly for Airflow deployment. The user that you use with "run as user" should be in the same group as the "airflow user" and umask should be set so that the file is group readable (at least - possibly group writeable).

[potiuk]

Proposed alternative solution with correcting airflow deployment, not airflow code.

[ashb]

Could this also be achieved by opening the file as airflow, before switching user and then changing the owner? That way the airflow process already has an open file handle and can just re-wind the filehandle to read it.

[potiuk]

Could this also be achieved by opening the file as airflow, before switching user and then changing the owner? That way the airflow process already has an open file handle and can just re-wind the filehandle to read it.

Hmm. Interesting idea :) I think indeed once you have filehandle, changing ownership should have no impact. Worth trying

[kevinbsilva]

Thank you for the tip! So, instead of using os.chmod we would use os.chown, right? This would avoid every user having access to the file. I will change that. Many thanks!

[ashb]

@kevinbsilva Does it work now? I think this should, but could you confirm?

[kevinbsilva]

@ashb i've tested in our development cluster and it works fine. But it seems a check from GitHub actions did not succeed. It raised a 404 when trying to install the Airflow.

[kevinbsilva]

Changed os.chmod to os.chown

[jhtimmins]

@kevinbsilva I think it received a 404 because the URL referenced master, which has recently been renamed main.

@potiuk can you take a look and confirm whether your requested changes have been addressed?

[ashb]

@kevinbsilva Could you rebase these changes to latest main branch please.

Alternate alternate approach has been done.

[github-actions]

The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease.

[jhtimmins]

@kevinbsilva looks like these are legit test failures that need to be addressed https://github.com/apache/airflow/pull/15947/checks?check_run_id=2794600747#step:6:14114

[kevinbsilva]

@jhtimmins i'm looking into it. Thank you, will update as soon as possible.

[ephraimbuddy]

@kevinbsilva please install pre-commit. That would be very helpful

[kevinbsilva]

@ephraimbuddy my mistake. I've read about the static checks and after executing some of the pre-commits, it is ok (mainly black and isort). Thank you very much!

I am getting errors from the MSSQL Build, but it don't seems that has any connection with the code update.

[ephraimbuddy]

@ephraimbuddy my mistake. I've read about the static checks and after executing some of the pre-commits, it is ok (mainly black and isort). Thank you very much!

I am getting errors from the MSSQL Build, but it don't seems that has any connection with the code update.

MSSQL is a known issue that is being worked on, not connected to your PR

[uranusjr]

This should either bubble the exception or log that the chown failed. Personally I’d prefer not catching the exception for now and fix UX issues when someone complains.

[kacpwoja]

Is it just me, or this breaks run_as_user completely? How can airflow run chown without sudo? Am I missing something?

[potiuk]

It does look suspiciously wrong here. I think it will only work is airflow is run as root

[potiuk]

@kacpwoja - maybe you can add PR to fix it (unless someone explains why it WOULD work of course)

[kacpwoja]

Yes, exactly as you said, it only works when airflow is run as root. When it's not, the tasks fail before they even start. I think we can use subprocess.call to invoke chown with sudo instead of using os.chown, just like a few lines above. I'll make a PR to fix this

[ashb]

Oh yeah, that is my bad. I entirely forgot that even if you own the file currently you can't change the owner unless you are root 🤦🏻

[ashb]

Airflow might not be able to sudo as root, but only sudo as a specific user :(

[potiuk]

I think the only solution is to create the file in a separate [sudo] (touch; chmod o+r) command and remove the file in finally clause or context manager (also with sudo). We can generate the temp file name with one of the uuids to get high probability that it's unique.

[kacpwoja]

Airflow might not be able to sudo as root, but only sudo as a specific user :(

But airflow already needs sudo permissions for chown anyway, as it uses it 20 lines before in the same file:
subprocess.call(['sudo', 'chown', self.run_as_user, cfg_path], close_fds=True)

If I recall correctly, Airflow also needs sudo permissions for rm and kill.

[potiuk]

Ah yeah. I looked at the docs https://airflow.apache.org/docs/apache-airflow/2.2.2/security/workload.html and we even mention that those permissions to change ownership of files (and root equivalence) is needed.