problems resulting from macos 'runner' user in wheel group

[sidney]

The default user 'runner' on the macOS runners is configured to be a member of group 0 (wheel). This is not necessary for sudo to be enabled for the user, as there is also an entry in /etc/sudoers for runner that does that. Note that on the Ubuntu runners, runner is enabled in sudoers and is not member of group 0.

Having user 'runner' in group 0 breaks some tests I run that check that it is not being run in an insecure configuration in which a process run as a non-root user has group 0 in its effective guid list. It is also not a standard configuration for macOS, so the behavior is unexpected.

If I remove 'runner' from the wheel group, the problem persists because the login process still has 0 in the gid list, and that is passed through to new processes that are launched unless I use sudo -u runner to launch a process with the change.

Here is example code that illustrates the problem, to be run in steps on a macos runner

  run: |
    # The id command shows what is configured, the perl command shows what is in a process that is run
    # first show that current user is 'runner' and it is in wheel(0) group
    id
    perl -e 'print "effuid $>  effgroups $)   realuid $< realgroups( $(\n";'
    # Now remove user 'runner' from wheel group in macOS system database
    sudo dseditgroup -o edit -d runner -t user wheel
    # show that change was made in the configuration
    id
    # show that the change does not take effect for processes launched by shell
    perl -e 'print "effuid $>  effgroups $)  realuid $<  realgroups $(\n";'
    # demonstrate the workaround I have to use on anything I run that needs it
    sudo -u runner perl -e 'print "effuid $>  effgroups $)   realuid $<  realgroups $(\n";'

Output from that (slightly reformatted):

uid=501(runner) gid=20(staff)
groups=20(staff),0(wheel),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin), 264(_webdeveloper),399(com.apple.access_ssh),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator), 204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing), 400(com.apple.access_remote_ae)
effuid 501  effgroups 20 20 0 12 61 79 80 81 98 264 399 701 33 100 204 250 395   realuid 501 realgroups( 20 20 0 12 61 79 80 81 98 264 399 701 33 100 204 250 395
uid=501(runner) gid=20(staff)
groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin), 264(_webdeveloper),399(com.apple.access_ssh),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator), 204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),400(com.apple.access_remote_ae)
effuid 501  effgroups 20 0 12 61 79 80 81 98 264 399 701 33 100 204 250 395  realuid 501  realgroups 20 20 0 12 61 79 80 81 98 264 399 701 33 100 204 250 395
effuid 501  effgroups 20 20 12 61 79 80 81 98 264 399 701 33 100 204 250 395 398   realuid 501  realgroups 20 20 12 61 79 80 81 98 264 399 701 33 100 204 250 395 398

On the Ubuntu runners the problem does not exist because user 'runner' is not in group 0. It does not have to be because sudo is enabled for it in the /etc/sudoers.d/runner file. On macOS there also no need to have user 'runner' in group 0 because it is enabled to run sudo in /etc/sudoers

Proposed fix: Remove user 'runner' from the wheel group in your macos runner configuration.