How can I tell the ec2 instance to switch to a non-root user via this runner?

[stas00]

All examples I have seen use a docker image, which has a user parameter.

But I'm not using docker. How do I then tell the action-runner to run as non-root (ubuntu in this case)

I tried many different ways, but no matter what I do the current user remains root

      - name: Who Am I?
        run: |
          sudo su - ubuntu
          whoami
      - name: Who Am I?
        run: |
          sudo -u ubuntu bash
          whoami
      - name: Who Am I?
        shell: bash -l {0}
        run: |
          su - ubuntu
          whoami

I can't find anything on the EC2 side that will let me change the default user. When I connect via ssh it gives the root@ip address.

I have everything already installed/configured under ubuntu.

If this is not the right place to ask if you know where I can find this info please let me know as I have spent many hours searching and can't find any information.

Thank you!

[machulav]

@stas00, the action starts the GitHub runner at EC2 instance launch using scripts entered as user data. And the official documentation says:

Scripts entered as user data are run as the root user

So, unfortunately, you can not start the runner from any other user except root with the action.

I hope that helps.

[jpalomaki]

While EC2 user data script is run as root, it is possible to use a non-root user if actions-runner is installed as a service (using the svc.sh script). See e.g. https://github.com/philips-labs/terraform-aws-github-runner/blob/develop/modules/runners/templates/install-config-runner.sh#L33

[stas00]

Thank you!

While EC2 user data script is run as root, it is possible to use a non-root user if actions-runner is installed as a service (using the svc.sh script)

Could ec2-github-runner support this?

[jpalomaki]

Thank you!

While EC2 user data script is run as root, it is possible to use a non-root user if actions-runner is installed as a service (using the svc.sh script)

Could ec2-github-runner support this?

I think it could, especially now with the newly-added runner-home-dir option (said pre-baked directory could be owned by that non-root user, so file permissions probably would not cause issues).

@machulav what do you think?

[stas00]

I already reinstalled everything to run under root, but it'd be much better not to. But absolutely no rush now that I have everything working under root.

[machulav]

I think it could, especially now with the newly-added runner-home-dir option (said pre-baked directory could be owned by that non-root user, so file permissions probably would not cause issues).

While the pre-baked directory could be owned by the non-root user, I believe that the runner still can be run only under root as the action still uses user data to start the runner. Not sure, though, how it works with the service approach as you mentioned above.

[jpalomaki]

@machulav I now tested this and it does appear that this type of step (when run on the self-hosted runner):

steps:
  - run: whoami

Does in fact print e.g. ubuntu, when starting the actions-runner as a service like so (this would replace ./run.sh):

...
./svc.sh install ubuntu
./svc.sh start

[jpalomaki]

@machulav See also https://github.com/actions/runner/blob/main/docs/automate.md#automate-configuring-self-hosted-runners

[andycockerill-cpi]

Hi, we are facing the same issue reported here. I'm trying to understand how @jpalomaki has managed to work around it. Did you create an AMI with the github runner already installed as a service?

[jpalomaki]

Hi, we are facing the same issue reported here. I'm trying to understand how @jpalomaki has managed to work around it. Did you create an AMI with the github runner already installed as a service?

I only tested the non-root service user approach using my own experimental action and AMI, which is unrelated to (but is inspired by) this project.

That said, I do think a similar approach could be implemented here as well. Philips-labs' terraform-github-runner-aws also supports it from what I can tell.

[andycockerill-cpi]

Thanks for the clarification. It is certainly a problem for us, one that we would like to see addressed.