Disable Local Network Access permission check

If only there was a way to disable local network access checks altogether

If only |-:

I recommend that you have a read through TN3179 Understanding local network privacy, just to confirm your understanding of the current state of affairs. If you still can’t find a solution that meets your requirement, you absolutely should file an enhancement request about this.

Please post your bug number, just for the record.

In the meantime, you should look to see if Homebrew has mechanism to sign code with a stable code-signing identity. If it does, then you should be abel to grant access once and have it persist across updates.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, Quinn! I've created an enhancement request and here's the bug number as requested: FB17818651.

I apologize if the "if only" came across as a bit snarky. I understand that not having such a setting is probably the right thing for macOS in the usual context of a personal computing device for end users. However, in a server context (where I guess Mac minis and Studios are quite popular), it might be warranted. Not sure if this audience is a priority for Apple.

As for Homebrew: I'm not a maintainer, but as far as I know, it only provides attestations for bottles (packages), and uses ad-hoc signing for the executables contained in the packages:

• https://repos.openssf.org/proposals/build-provenance-and-code-signing-for-homebrew.html#macos-executable-code-signing
• https://github.com/Homebrew/brew/blob/1f37a11b7946b6d770ecba66a487ba325b58e49c/Library/Homebrew/extend/os/mac/keg.rb#L40

Thanks for filing FB17818651.

I apologize if the "if only" came across as a bit snarky.

Oh, that’s not how I interpreted at all (-: Speaking personally, I’d love to see more options for folks in your situation.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks! I hope there's a chance of a solution materializing during Tahoe's development.

In the meantime, I'll probably revert back to launch daemons because the permission problem is worse than I thought. It's one thing when I have to log in using remote desktop to re-grant permissions after upgrading Prometheus, Grafana, Alloy, or other services, but it's another when I upgrade a runtime like Pythong or .NET. In that case, I have to figure out which services use those, restart them, and then allow access to the local network and private keys in Keychain.

Running as root is already not great, but launch daemons often surface another problem: because they start so early in the boot process, network interfaces might not be up yet and some services don't properly handle that case. Technitium DNS, for example, falls back to listening on a default port on all interfaces if binding fails. I've filed an issue upstream and the next version will introduce a flag which instead terminates the process, so that launchd can restart it at a later time. There are other cases like this.

Just mentioning this additional context in case it helps with prioritization :)

because [launchd daemons] start so early in the boot process, network interfaces might not be up yet

Indeed. Programs running on Apple platforms are expected to respond gracefully when the network configuration changes, but programs with a Unix-y herigate often don’t. Historically launchd supported the NetworkState property to help with that, but it looks like we removed that compatibility sop at some point.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

It's been a while, but I wanted to bring up the topic again in the hopes that it would increase the changes for improvements in the next major macOS release.

People got very creative in the meantime and they use solutions like https://github.com/steipete/Peekaboo or https://www.hammerspoon.org to automate away the security prompts (or just run services as root). As a result, systems become less secure - the opposite of what the permission dialogs are aiming for. It would be better to allow for some flexibility and selectively disable the local network permission for people who trust their networks, the machines, and the software they install on them. Maybe there's a smart way to solve that only for certain use cases like LaunchAgents.

Thanks for the ping. It’s reminded me that I do have some additional news on this front, but it’ll have to come via an update to TN3179 (r. 161891509). And, hey, this is as good a time as any to kick off that work…

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Alright, I'll watch TN3179 for updates! I don't see a revision number like 161891509 in the public docs, so I assume it's an internal reference. Hoping for good news :)

I don't see a revision number like

Ah, sorry for the confusion there. That’s a Radar bug number. You won’t be able to access it directly. See Bug Reporting: How and Why? for more about that.

I’ll make sure to include that bug number in the revision history of the TN3179 update.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We just posted a TN3179 update with info about the AllowedEthernetLocalNetworkAddresses and AllowedWiFiLocalNetworkAddresses user defaults. I think this might be useful in your situation, where you have limited control over the software involved but deep control over the Mac on which it runs.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Quinn, this is awesome, thank you so much!

And wow: "The AllowedEthernetLocalNetworkAddresses and AllowedWiFiLocalNetworkAddresses user defaults debuted in macOS 15.5"