Requiring sudo privilages

[mluscon]

Apache Airflow version

2.2.3 (latest released)

What happened

If airflow worker process is run under non-root user and a dag contains run_as statement, airflow calls sudo chown during the creation of tmp files. The following code snippet comes from /airflow/task/task_runner/base_task_runner.py .

        if self.run_as_user and (self.run_as_user != getuser()):
            # We want to include any environment variables now, as we won't
            # want to have to specify them in the sudo call - they would show
            # up in `ps` that way! And run commands now, as the other user
            # might not be able to run the cmds to get credentials
            cfg_path = tmp_configuration_copy(chmod=0o600, include_env=True, include_cmds=True)

            # Give ownership of file to user; only they can read and write
            subprocess.check_call(
                ['sudo', 'chown', self.run_as_user, cfg_path, self._error_file.name], close_fds=True
            )

            # propagate PYTHONPATH environment variable
            pythonpath_value = os.environ.get(PYTHONPATH_VAR, '')
            popen_prepend = ['sudo', '-E', '-H', '-u', self.run_as_user]

Calling sudo chown in subprocess actually requires airflow process user to be able to sudo to root which averts the main point of running airflow worker process as a non-root user. I would therefore propose to allow run_as_user read and write by setting facl attributes of tmp file accordingly.

Will you be willing to accept a PR addressing this issue via setfacl?

What you expected to happen

No response

How to reproduce

No response

Operating System

Linux

Versions of Apache Airflow Providers

No response

Deployment

Docker-Compose

Deployment details

No response

Anything else

No response

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

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[potiuk]

Why do you want to do it? Few lines below you have the "sudo" command to run the command as the other user. What woudl setfacl change in this case if you anyhow need to give airflow user to be added to sudoers ?

popen_prepend = ['sudo', '-E', '-H', '-u', self.run_as_user]

[potiuk]

Looked a bit closer - I assume you only want to add the "airflow" user a capability to only sudo to "run_as_user" but not to root? Seems doable.

Did you test if all will work in this case? Does FACL not require any special permissions to set the file to be owner by the "run_as_user""?

If so - feel free to make a PR. But please remember to update "impersonation" documentation.

[potiuk]

BTW. Is there a chance that setfacl command will be unavailable or configured not to work? I guess we can conditionally run the old sudo way in case it fails just in case?

[potiuk]

Ah yeah - acl needs to be enabled when you mount partition as mount option, so while it does make sense, you need to add it to impersonation prerequisites and provide fallback to sudo in this case.

[potiuk]

But it is a nice feature indeed.

BTW. Just to correct your statement - the current option with sudo does NOT avert the main purpose. Maybe there is a misunderstanding about the purpose of impersonation.

The purpose of impersonation is not to prevent the "airflow" user to run as root, but to make sure that the "task" coming from DAG wirtten by DAG author is executed only using the "target run_as_user" (which does not have sudo). So it worked fine before as expected.

The FACL solution simply changes the requirements that the airflow user must fullfill to be able to use impersonation.

Instead of having sudo as root, the "${TMP_DIR}" folder must be mounted on acl-enabled volume and the airlfow user should be able to sudo as run_for_user.

[mluscon]

Looked a bit closer - I assume you only want to add the "airflow" user a capability to only sudo to "run_as_user" but not to root? Seems doable.

Exactly, my "airflow" user is capable of impersonating all of run_as_users that I am using but not root.

[eladkal]

@mluscon will you PR a fix?

[G-S-Paris]

@mluscon, @potiuk I have this same usecase - I can assign my "airflow-user" sudoer access to my desired "run_as_" users, but I'll never be able to giving my airflow-user root access via sudoer in my environment.

Where did y'all get with the change previously? I haven't worked with FACL before but I'm willing to give it a shot

[potiuk]

Have you seen https://airflow.apache.org/docs/apache-airflow/1.10.10/security.html?highlight=impersonation#impersonation ? @G-S-Paris - maybe that will be enough for your case.

[potiuk]

BTW. I guess - if not - then no-nothing happened here as far as I see (and I see the same that you see) and if you would like to pick it up, then feel free @G-S-Paris

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open for 365 days without any activity. There has been several Airflow releases since last activity on this issue. Kindly asking to recheck the report against latest Airflow version and let us know if the issue is reproducible. The issue will be closed in next 30 days if no further activity occurs from the issue author.

[github-actions[bot]]

This issue has been closed because it has not received response from the issue author.