Local Network Access Permission requires binary to have LC_UUID load command

As mentioned in https://developer.apple.com/forums//thread/759955 I was having trouble on macOS 15 with a launch agent accessing local network resources, even if the local network permission dialog pops up, and Settings app visually claims the app has permission granted.

The following was logged:

nehelper +[NEProcessInfo copyUUIDsForExecutable:]_block_invoke: failed to get UUIDs for /Users/foo/my-binary

It turned out that the problem was caused by the default golang toolchain not producing a LC_UUID load command, which seems to be critical for the network privacy subsystem to determine whether the binary is allowed access or not.

The issue has been reported upstream here: https://github.com/golang/go/issues/68678

To work around this I added -ldflags="-linkmode=external" when building the go binary, so that the system linker (which does add LC_UUID) is invoked.

Answered by DTS Engineer in 798090022

It turned out that the problem was caused by the default golang toolchain not producing a LC_UUID load command, which seems to be critical for the network privacy subsystem to determine whether the binary is allowed access or not.

Basically, yes, things can get weird when an executable doesn't include LC_UUID and that's an issue they need to fix in their toolchain. This is one example, but the biggest issue (in my view) is that it breaks any kind of automatic symbolication, since that UUID is how our system matches crash logs to symbol files.

Filed FB14587785 to track the confusing situation of the UI reflecting granted permission, while not working in practice.

It's a reasonable bug, however, IMHO the "fix" here should be to reject the extension as invalid at load time. Executable need to include build UUIDs.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Filed FB14587785 to track the confusing situation of the UI reflecting granted permission, while not working in practice.

The UUID behavior is also described here https://forums.developer.apple.com/forums/thread/737416

Accepted Answer

It turned out that the problem was caused by the default golang toolchain not producing a LC_UUID load command, which seems to be critical for the network privacy subsystem to determine whether the binary is allowed access or not.

Basically, yes, things can get weird when an executable doesn't include LC_UUID and that's an issue they need to fix in their toolchain. This is one example, but the biggest issue (in my view) is that it breaks any kind of automatic symbolication, since that UUID is how our system matches crash logs to symbol files.

Filed FB14587785 to track the confusing situation of the UI reflecting granted permission, while not working in practice.

It's a reasonable bug, however, IMHO the "fix" here should be to reject the extension as invalid at load time. Executable need to include build UUIDs.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Local Network Access Permission requires binary to have LC_UUID load command
 
 
Q