Fix "Access denied" problem in the `git-artifacts` CI runs

[dscho]

I have now hit this consistently, a couple of times, e.g. here: When the installer job of git-sdk-arm64's git-artifacts workflow tries to verify that the installer works, it fails. When you download the installer logs, you can see that it is always the same issue:

[...]
2025-02-05 15:02:20.819   Installing the file.
2025-02-05 15:02:20.819   Defaulting to Abort for suppressed message box (Abort/Retry/Ignore):
                          C:\Program Files\Git\unins000.exe
                          
                          An error occurred while trying to create a file in the destination directory:
                          Access is denied.
2025-02-05 15:02:20.821   User canceled the installation process.
2025-02-05 15:02:20.821   Rolling back changes.
2025-02-05 15:02:20.821   Starting the uninstallation process.
2025-02-05 15:02:20.824   Uninstallation process succeeded.
2025-02-05 15:02:20.824   Deinitializing Setup.
2025-02-05 15:02:20.846   Log closed.

The installer cannot (maybe over-)write unins000.exe.

Could the problem be that Git for Windows is installed using a different account in self-hosted runner VMs than the actual GitHub Actions runner ends up running as?

@dennisameling any ideas?

[dennisameling]

Hmm, interesting.

• The post-deployment script that we use to install GfW in the VM apparently runs under the LocalSystem account.
• In said script, the GitHub Actions runner is configured to run as a system service. It runs as NT AUTHORITY\NETWORK SERVICE by default (just confirmed by installing a runner locally). This is configurable though, by adapting the config.cmd invocation:

PS C:\actions-runner> ./config.cmd --help

Commands:
 .\config.cmd         Configures the runner
 .\config.cmd remove  Unconfigures the runner
 .\run.cmd            Runs the runner interactively. Does not require any options.

Options:
 --help     Prints the help for each command
 --version  Prints the runner version
 --commit   Prints the runner commit
 --check    Check the runner's network connectivity with GitHub server

Config Options:
 --unattended           Disable interactive prompts for missing arguments. Defaults will be used for missing options
 --url string           Repository to add the runner to. Required if unattended
 --token string         Registration token. Required if unattended
 --name string          Name of the runner to configure (default SURFACEPROX-DA)
 --runnergroup string   Name of the runner group to add this runner to (defaults to the default runner group)
 --labels string        Custom labels that will be added to the runner. This option is mandatory if --no-default-labels is used.
 --no-default-labels    Disables adding the default labels: 'self-hosted,Windows,Arm64'
 --local                Removes the runner config files from your local machine. Used as an option to the remove command
 --work string          Relative runner work directory (default _work)
 --replace              Replace any existing runner with the same name (default false)
 --pat                  GitHub personal access token with repo scope. Used for checking network connectivity when executing `.\run.cmd --check`
 --disableupdate        Disable self-hosted runner automatic update to the latest released version`
 --ephemeral            Configure the runner to only take one job and then let the service un-configure the runner after the job finishes (default false)
 --runasservice   Run the runner as a service
 --windowslogonaccount string   Account to run the service as. Requires runasservice
 --windowslogonpassword string  Password for the service account. Requires runasservice

Examples:
 Check GitHub server network connectivity:
  .\run.cmd --check --url <url> --pat <pat>
 Configure a runner non-interactively:
  .\config.cmd --unattended --url <url> --token <token>
 Configure a runner non-interactively, replacing any existing runner with the same name:
  .\config.cmd --unattended --url <url> --token <token> --replace [--name <name>]
 Configure a runner non-interactively with three extra labels:
  .\config.cmd --unattended --url <url> --token <token> --labels L1,L2,L3
 Configure a runner to run as a service:
  .\config.cmd --url <url> --token <token> --runasservice

Let me check if I can reproduce the issue locally and then see if running as NT AUTHORITY\SYSTEM fixes the issue. In the end, we're running in isolated VMs, so granting these permissions should be fine.

[dennisameling]

Can confirm that tweaking the ./config.cmd invocation by adding --windowslogonaccount "NT AUTHORITY\SYSTEM" fixes the issue.

@dscho would you be OK with this solution? We can update the invocation here.

[dscho]

@dennisameling we may want to consider two alternatives:

• installing Git for Windows as NT AUTHORITY\NETWORK SERVICE in the create-self-hosted-runner workflow, or
• installing Git for Windows to a different location than C:\Program Files instead.

On the other hand, it is quite curious that microsoft/git has no problems installing Git for Windows as part of the validate job in the build-git-installers workflow, see e.g. here. I'll see how Git for Windows is installed there.

[dscho]

it is quite curious that microsoft/git has no problems installing Git for Windows as part of the validate job in the build-git-installers workflow, see e.g. here.

I think the solution to that riddle is that the hosted runners run as runneradmin who is part of the administrators group. So I went with the lowest-friction work-around to start the self-hosted runner as SYSTEM (to avoid the hassle of having to recreate the runneradmin account).

Eventually, we might even have public Windows/ARM64 runners hosted by GitHub, in which case all this hassle we went through here will be made obsolete.