Local Network Access Permission requires binary to have LC_UUID load command

Question

Created Jul ’24

Replies 3

Boosts 0

Views 1.2k

Participants 2

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.

Boost

Answer 1

torarnv OP

Jul ’24

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

0

Answer 2

torarnv OP

Jul ’24

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

0

Answer 3

DTS Engineer OP

Apple

Jul ’24

Accepted Answer

Recommended

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

1