add "local network access" permission for macOS 15 runners
Description
Attempting to test multicast sockets results in routing errors, which suggests that the code is running without "local network access" permissions.
Ideally this would be configurable, so that code could be tested to ensure that it doesn't need this permission, but when it is necessary for a certain function it would be nice to have.
Platforms affected
- [ ] Azure DevOps
- [X] GitHub Actions - Standard Runners
- [X] GitHub Actions - Larger Runners
Runner images affected
- [ ] Ubuntu 20.04
- [ ] Ubuntu 22.04
- [ ] Ubuntu 24.04
- [ ] macOS 12
- [ ] macOS 13
- [ ] macOS 13 Arm64
- [ ] macOS 14
- [ ] macOS 14 Arm64
- [X] macOS 15
- [X] macOS 15 Arm64
- [ ] Windows Server 2019
- [ ] Windows Server 2022
Image version and build link
https://github.com/twisted/twisted/actions/runs/11713225981/job/32625578908?pr=12357
Is it regression?
sort of? it regressed from macos 14
Expected behavior
I would expect to be able to test multicast sockets
Actual behavior
Multicast sockets give a "no route to host" error when sending
Repro steps
- bind a multicast socket
- send some data to it
@glyph We will look into the issue and keep you posted with updates.
@glyph We will look into the issue and keep you posted with updates.
Thank you!
Hi @glyph Apple introduced new LNP policy with macOS Sequoia which is not controlled by TCC or MDM. We are working on resolving this. For more information see there: thread , thread
Thanks for the context, @sureshe456 !
Hi @glyph, We reported this issue to the Apple forum, and they responded as follows , please go through the below link, and we are currently working on it but unclear precious solution,We are trying to find a feasible solution. Please allow us some time to explore more options and respond. Thanks. https://forums.developer.apple.com/forums/thread/770473
Thanks again for following up @sureshe456 . I made a comment on that thread. This seems like a real bummer of a change from Apple; I hope that they respond to your bug report when you file it, and address this in an update.
Hi @glyph, Opened Apple Feedback to report this: FB16213134
Hi @glyph, Opened Apple Feedback to report this: FB16213134
Thanks again, good to have the bug number. (FYI, the actual link to the feedback number doesn't do anything for anyone outside apple; the feedbacks themselves are confidential.)
Hi @glyph We are still waiting an update from Apple side. Will update here once we have any update.
Hi @glyph We have followed up on the submitted request, but there haven’t been any updates from Apple yet. Thank you. https://developer.apple.com/forums/thread/770473.
Sorry that they're leaving you in the lurch here @sureshe456 . Good luck and I hope you get a response soon.
HI @glyph We kept following up with the Apple support team for this issue and received a response from them to follow the links below. We understand that there are restrictions on local network access and that it is deactivated by default, but it can still be run, follow the MAC configuration link..
Thanks, this is a useful resource. However, it's not clear to me how this is supposed to apply in Github Actions as a user. How are jobs run right now, if not as launchd daemons, running as root, running via an SSH processes, or in a Terminal? Is there some actions yaml key I could set to request that it be one of those things, instead, to be granted local network access in this way?
oh, I guess this is an option:
The Linux and macOS virtual machines both run using passwordless sudo.
I could run some subset of the test suite as root on macOS to sidestep this for the time being? That is way more privileges than this code needs, so I hope a more nuanced approach is available in the future, but this is somewhere to start...
My macos-15 issue was a duplicate of this. But since 3 days ago, I am now having issues with ubuntu images also. Attempts to establish a tcp connection between two binaries, that always worked before, now hang and tests run forever.
Hi @andrewdavidmackenzie Kindly raise a new ticket with this issue for ubuntu images because we are supporting issues related macOS images. Thanks.
Hi @glyph Mean time,Please refer to the link for local network access privacy FAQ according to "What operations require local network access?" chapter we can find more information there.
We are also checking for any workaround to add LAN permission for macOS 15 image. Thanks.
Hi All, Currently we don't have any updates on the issue, Still we are checking workaround for add Local network access permission. Thanks for your patience.
Hi All, We have not received any updates from Apple side and will keep you posted on any further developments. We appreciate your patience. Thanks.
@sureshe456 how do you run the GHA Runner script?
We at Cirrus Runners implemented a workaround: our launcher is executed as root but immediately drops privileges to runner user before running ./run.sh .... Also please make sure that your macOS VM is configured to auto-login for runner user.
Hi @glyph Mean time,Please refer to the link for local network access privacy FAQ according to "What operations require local network access?" chapter we can find more information there.
We are also checking for any workaround to add LAN permission for macOS 15 image. Thanks.
I see in the apple docs that network access is granted to any
"Command-line tools run from Terminal or over SSH, including any child processes they spawn "
I guess that doesn't apply to processes spawned in the image by GH Actions, only ones by a real user typing at "Terminal"?
It also states access is granted to processes running as root, I wonder if running my tests as root would work around the local network access restrictions?
Hi @glyph Mean time,Please refer to the link for local network access privacy FAQ according to "What operations require local network access?" chapter we can find more information there.
We are also checking for any workaround to add LAN permission for macOS 15 image. Thanks.
I see in the apple docs that network access is granted to any
"Command-line tools run from Terminal or over SSH, including any child processes they spawn "
I guess that doesn't apply to processes spawned in the image by GH Actions, only ones by a real user typing at "Terminal"?
It also states access is granted to processes running as root, I wonder if running my tests as root would work around the local network access restrictions?
I tried for about a week to find various workarounds to try to make the actions runner work within the carve outs that Apple has designated, without much luck. I ended up with a launch agent that runs an Apple script. You can follow my full journal of approaches https://developer.apple.com/forums/thread/787469
YMMV with root. It does work, but I ran into second order complications.
Closing that item as not fixable and stale. This is our new reality for macOS. 😞
@brianmichel have you managed to install this clicker agent automatically on a GHA runner? I'm wondering if there's any ready-to-use version of this.
@brianmichel have you managed to install this clicker agent automatically on a GHA runner? I'm wondering if there's any ready-to-use version of this.
I have successfully packed this into our own VM image that gets booted on our infrastructure, but I haven't tried to install it from a GitHub workflow onto a GitHub runner. We use our own runners so it made more sense for me to pack it into our images.
I did see that GitHub is getting some kind if custom image functionality, so maybe this would be possible by others using GitHub actions runners in the future?
Otherwise I think GitHub would have to build this into their macOS image directly.
Edit: actually it looks like the GitHub runner custom images feature doesn't support macOS custom images, https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/use-custom-images. So unless GitHub installs a launch agent that runs this clicker script I'm not sure it's possible to install as part of a workflow.
Another option that I believe should work is to totally disable code signing on your CI builds for testing and also supply a different entitlements file that only includes entitlements that don't require a provisioning profile. Granted my context for solving this problem is specifically for macOS apps, YMMV if you're solving this for the iOS Simulator.
I'm happy to share the xcconfig values and an example entitlements file when I get to work today if you might be interested in that @glyph just let me know.
Otherwise I think GitHub would have to build this into their macOS image directly.
I'd be happy to discuss your proposal and your existing implementation. The clicker we can find in the external thread has its drawbacks, but all things being equal, it provides at least some kind of solution, which is valuable given the overall situation.
@erik-bershel thank you for reopening! it would be great to have a solution before the last image that lets us test this functionality on any version of macOS ages out.
I'm happy to share the xcconfig values and an example entitlements file when I get to work today if you might be interested in that @glyph just let me know.
I don't think I can use these directly, and I'd rather use the official fix anyway — but I do think it would be interesting if you could share them just to help everybody out who is having to contend with this problem
macos-26 image also affected