Local Network permission prompt for daemon on macOS 15

Can you confirm that that is by design?

No.

My take on this is that your daemon is running in an unsupported configuration and thus it’s hard to predict what local network privacy is going to do.

My experience is that:

• A daemon running as root can access the local network just fine [1].

• An agent running in the GUI login session can access the local network subject to user approval.

what is the point of the UserName field in the launchd plist file then?

For role accounts.

I'm really struggling to find where it says anywhere in the developer documentation that what we are doing is "not a supported configuration".

Our documentation generally does not tell you what you can’t do; rather, it tends to focus on what you can [1]. And the design I’m recommending here is clearly described in the The Perils of the Monolith section of Technote 2083 Daemons and Agents.

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

[1] On macOS 15.1 and later. On macOS 15.0 there’s a gnarly bug that affects this case.

[2] Having said that, the Daemons Accessing User State section of TN2083 says “It is not possible for a daemon to act on behalf of a user with 100% fidelity”, and that seems pretty clear to me. The example it uses to illustrate this claim is no longer relevant, but the statement itself is still correct.

So why doesn't the manual documentation say "This optional key specifies the role account to run the job as" then?

You keep saying it's an unsupported configuration when it clearly isn't - at least, it hasn't been an unsupported configuration for years over numerous macOS iterations.

If something has changed and it's now not supported then you need to update your documentation and manuals.

The report here is that daemons running as an administrator user account (which has always been a supported configuration) cannot for some reason communicate over UDP. At least look into why that is please.

You keep saying it's an unsupported configuration when it clearly isn't

You are arguing about what is or isn’t supported with someone whose literal job title is Developer Technical Support engineer. Speaking for DTS as a whole, we don’t support this monolithic approach. That’s because our goal is to help developers build software that works now and in the future, and the monolithic approach is likely to have ongoing problems are macOS evolves. So, even if you get past this issue, more issues are waiting for you down the pike.

I you believe that the documentation should do a better job of explaining this reality, please do file a bug against it. If you believe that macOS should support your monolithic design, you can file a bug requesting that too. If you do file any bugs, I’d appreciate you posting the bug numbers, just for the record.

If you would like to explore non-monolithic designs, I’d be happy to answer your questions on that front.

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

I appreciate that you are an actual DTS engineer, and well done on that score, very impressive indeed.

Unfortunately that doesn't have any bearing whatsoever on the fact that daemon servers used to be able to be run with user permissions and now cannot.

The upshot of this is that it's categorically impossible to update our software to work fully on the latest version of macOS. We can either choose between a working server and no local device access or local device access and a broken server. A split up application using IPC calls isn't even an option because we'd need a user session to access the camera.

This is a shame as i'm currently sitting in an office surrounded by completely useless hardware and have lost a month of development time and we're no closer to a resolution. Your goal of helping developers build software now and in the future has failed spectacularly in our admittedly rather specific case as this is the future from when it worked fine in the past.

Fortunately macOS is a small part of our user base and we'll just have to tell people to use Linux or Windows instead and hope that at some point this is resolved.

We're having exactly the same issue running our application as a LaunchAgent as we did running it as a LaunchDaemon

No route to host at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow)

https://github.com/ispysoftware/agent-install-scripts/blob/main/v2/launchagent.plist

It just doesn't work.

We've done everything to try to get this working. We get the exact same errors in the console when running it as a launch agent that we did when running it as a launch daemon

OK the thing that has cost us all this grief is that as of Sequoia the application needs to be running in /Applications - we've been testing it from the desktop folder/ other folders on the OS. For some reason if it's not running in /Applications you get this weird UDP error. Even if it's running as root. Moving it to /Applications has resolved all the issues.

Apple, why do you do this?