Avoid need for Administrator rights on Windows

Describe the bug I’m using this action with a self-hosted runner on Windows. As described in the readme, under this scenario, the action needs to run as Administrator in order to set up new Python versions. But this clashes with running the self-hosted runner as a service under NT AUTHORITY\NETWORK SERVICE, and it seems unwise to run the service as Administrator.

Ideally, the action could avoid needing Administrator rights by installing Python just for the current user, or by using one of the embeddable packages of Python that don’t involve an MSI.

Which version of the action are you using?

• v1
• v2
• Some other tag (such as v2.0.1 or master)

Environment

• self-hosted
• Linux
• Windows
• Mac

Python Versions 3.9.2 x64

To Reproduce With the self-hosted runner running as a service using default settings, and starting with an empty work folder, run the action to trigger a Python installation attempt failure. The log ends with:

Install Python 3.9.2 in C:\actions-runner\_work\_tool\Python...

Error: Error happened during Python installation
Error: At C:\actions-runner\_work\_temp\9353962a-1e9f-484c-bb48-761d49ade1c8\setup.ps1:121 char:5
+     Throw "Error happened during Python installation"
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Error happened ...on installation:String) [], RuntimeException
    + FullyQualifiedErrorId : Error happened during Python installation
Error: The process 'C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe' failed with exit code 1

Workaround

1. Pin the version of Python installed by the action, so future minor and patch releases won’t trigger an install attempt that will result in failure. (assuming that automatic upgrades can happen)
2. With the self-hosted runner running as Administrator, run the workflow(s) that install the version(s) of Python needed.
3. For subsequent runs, the self-hosted runner can run as a service under NT AUTHORITY\NETWORK SERVICE.

[brcrista]

@carsonyl it all depends on your project. If it’s a small private repo and you trust everyone who has access, then running a self-hosted runner on a workstation might be fine. As you get into a bigger private repo or a public repo, that becomes pretty risky and you should consider dedicated build infrastructure.

If you’re maintaining self-hosted runners for a big project, I’d recommend looking at https://github.com/actions-runner-controller/actions-runner-controller and enabling the ephemeral feature. That will make sure each job runs in a clean environment, just like using a GitHub-hosted runner.

[marko-zivic-93]

Thank you guys! I will now close this issue due to the fact that we are not going to pursue implementing it. @carsonyl if you have any additional concerns or questions, please feel free to leave a comment here or to create a new issue.