admin user required on self-hosted runner

[daiyam]

Description:
On a self-hosted runner, the install script requires that the user starting the runner to be an admin (due to the sudo commands).

Action version:
4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
3.11.6

Expected behavior:
Successful install

Actual behavior:
Asking for a password and fails due to not running as an admin user

[dmitry-shibanov]

Hello @daiyam. Thank you for your report. We'll take a look on it.

[mcaulifn]

@dmitry-shibanov Do you have an update on this? Also getting for macos14 installing 3.12

[BodhiMadness]

Hey @dmitry-shibanov - Can we take another look at this and make it a priority?

[chase]

Ideally this would just be relegated to an unprivileged addition to PATH instead of requiring the user to be a sudoer/admin.

Stranger still that the user must be named runner for it to work.

[nickbianco]

I am also getting this error macOS 14 installing Python 3.11.

[plink-plonk-will]

Currently the workarounds are:

1. If your user is not runner you need to fix that as per docs here: https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#macos

2. To bypass the sudo requiring a password issue, you need to make your user a NOPASSWD sudoer. This is not ideal of course, and the simplest way I found was here:
   https://jefftriplett.com/2022/enable-sudo-without-a-password-on-macos/

You could add that for just the runner user of course and not the entire admin group.

[fingerart]

My user is runner and cannot be installed normally.

Run actions/setup-python@v5
Installed versions
  Version 3.9 was not found in the local cache
  Version 3.9 is available for downloading
  Download from "https://github.com/actions/python-versions/releases/download/3.9.13-8879985561/python-3.9.13-darwin-arm64.tar.gz"
  Extract downloaded archive
  /usr/bin/tar xz -C /Users/runner/actions-runner/_work/_temp/ec7e2ff5-6535-47ee-bc2b-48d04231a562 -f /Users/runner/actions-runner/_work/_temp/564640f7-10ab-40b0-85f0-94e87921f7fd
  Execute installation script
  Check if Python hostedtoolcache folder exist...
  Creating Python hostedtoolcache folder...
  Install Python binaries from prebuilt package
  Error: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
  Error: sudo: a password is required
  Error: The process '/bin/bash' failed with exit code 1

[plink-plonk-will]

@fingerart

2. To bypass the sudo requiring a password issue, you need to make your user a NOPASSWD sudoer. This is not ideal of course, and the simplest way I found was here:
   https://jefftriplett.com/2022/enable-sudo-without-a-password-on-macos/

You could add that for just the runner user of course and not the entire admin group.

[IanTaylor-catapult]

I'm encountering the same issue. When trying to install python with the setup-python@v5 action on a macstadium orka runner I get this error...

I go through the setup process detailed in the docs here...
https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#macos

Which looks like this in the pipeline...

Fully stuck here. Outside of disabling the password requirement for sudo and regenerating the image we're using, I'm unsure how to solve it. Any help would be appreciated.

[IanTaylor-catapult]

Workaround is to set sudoers to NOPASSWD to avoid the prompt for your automation user. Insecure and bad, but it seems to work.

[fryette]

Workaround is to set sudoers to NOPASSWD to avoid the prompt for your automation user. Insecure and bad, but it seems to work.

This is a bigger security issue than a workaround.

[mahabaleshwars]

Hello @daiyam,

When using self-hosted runners, it's important to ensure that all necessary dependencies, including Python, are properly installed and configured to avoid issues like the ""sudo: installer: command not found"" error.

In your case, the issue arises because the install script requires the user starting the runner to have admin (sudo) privileges, which is necessary for certain operations like installing dependencies.

Here are a few steps to address this:

• Ensure the installer command is available and in the PATH: The installer command needs to be accessible by the runner to function correctly.
• Verify that the workflow user has the necessary permissions: The user starting the runner must have admin privileges (sudo access) to run the installer commands. If the workflow user doesn't have these permissions, consider either modifying user permissions or running the runner as an admin user.
• Pre-install required Python versions: To avoid the need for runtime installations, you can pre-install the necessary Python versions on your self-hosted runner. This eliminates the need for the install script to rely on sudo commands during workflow execution.

Self-hosted runners are fully customizable to meet your specific environment needs. For more information on setting up and troubleshooting self-hosted runners, please refer to the Using self-hosted runners documentation and Using setup-python with a self-hosted runner

[vanyasem]

The only command that seems to be executed with sudo seems to be sudo installer -pkg $PYTHON_PKG_NAME -target /

You can override the default sudo behavior for a single command, allowing only that command to be executed without being prompted for the password

In our case, the command in question is installer

Execute sudo visudo, and add the following lines to the sudoers file:

## No pw for installer
%admin ALL=(ALL) NOPASSWD: /usr/sbin/installer

[vanyasem]

refer to the Using self-hosted runners documentation and Using setup-python with a self-hosted runner

TLDR, run this once after configuring visudo as mentioned above:

mkdir -p /Users/runner/hostedtoolcache
sudo chown -R runner:staff /Users/runner/hostedtoolcache

I can confirm that the action works as intended with changes to sudoers:

I guess this could be included in the documentation @mahabaleshwars @priya-kinthali @aparnajyothi-y @HarithaVattikuti

[mahabaleshwars]

Hello @vanyasem,

While allowing sudo installer to run without a password might be convenient, it poses several security risks. These risks are primarily due to the potential for privilege escalation, malicious package installation, and lack of accountability. For these reasons, this approach is not recommended, and the documentation cannot be updated to reflect this workaround.

[vanyasem]

@mahabaleshwars I do agree with your point. However, allowing installer binary to be executed without a password is much better than the other proposed solution that involves making the entire user a NOPASSWD sudoer:

2. To bypass the sudo requiring a password issue, you need to make your user a NOPASSWD sudoer. This is not ideal of course, and the simplest way I found was here:
   https://jefftriplett.com/2022/enable-sudo-without-a-password-on-macos/

Originally posted by @plink-plonk-will in #760 (comment)

The idea behind my suggestion to mention it in the docs is to highlight the security implications of the solution, and to guide users to the least priveledged option. The solution to add the entire user as a NOPASSWD sudoers gets mentioned a lot, and it's being used in the wild, despite it being a massive security vulnerability. Linking to a least drastic option could be useful imo. But if you feel that it doesn't belong in the docs, I'm fine with that.

Thanks for the reply, I appreciate the work you're doing.

[mahabaleshwars]

Hello @daiyam,

Could you kindly confirm if the feedback provided has resolved your issue?

[daiyam]

I haven't tested it since NOPASSWD isn't a secure solution.

[mahabaleshwars]

Hello @daiyam, You can review this feedback and see if it helps resolve your issue.

[mahabaleshwars]

Hello @daiyam,
Just wanted to follow up and see if the feedback provided has helped resolve your issue.
Let me know if you need any further assistance!