Local Network Permissions - launchd service running as non-root user

That’s a lot of complicating factors. I’d like to start by understanding the context in which your code is started. Are you running it as a launchd daemon or a launchd agent? That is:

• Did you put the launchd property list in /Library/LaunchDaemons and then configure the user via the UserName property in that property list?

• Or did you put the launchd property list in /Library/LaunchAgents or ~/Library/LaunchAgents?

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

I am doing the first option of putting the launchd property list in /Library/LaunchDaemons and then configure the user via the UserName property in that property list. This plist calls a shell script which starts up the java process with proper arguments.

Is that a role account? Or a real user?

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

It is a real user

Any thoughts about this scenario?

Thanks

Hi,

I have the exact same problem. Trying to launch a service through launchd with UserName in the property list in /Library/LaunchDaemons

It seems nothing is working, I can't access Local Network with my service. As soon as I remove the UserName so it run as root, this is working as expected.

Any news about this ? Did someone find a way to use UserName ?

I have not found a way to get this to work at all. I think its pretty clear at this point this is a bug and this whole local network permission speedbump didn't account for all cases where it would be required

I have a ticket open with Apple in Feedback assistant. Hopefully i get more info from them because its gone cold here.

Sorry I didn’t reply sooner. I missed the updates back in Jan.

What’s the intention behind that?

Running a launchd daemon as a real user tends to cause weird problems because launchd switches the BSD component of the execution context but not all the other components. So, if your code uses APIs that rely on these other bits of execution context then you see undefined behaviour. A classic example of this is using the Security framework, but there are many others, including anything to do with privacy privileges.

Note I talk about execution contexts in TN2083 Daemons and Agents. That’s super old, something you need to keep in mind as you read it, but the core ideas are still sound.

OK. Then I have the same question for you: What’s the intention behind configuring your daemon in this way?

Please post you bug number.

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

Basically it would be the same intention as with any daemons/services or anything, I prefer to give the least permissions as possible to my daemon I can and not a full access, so I'm sure if anything happens it won't have access to everything in my mac.

Running it as a user and not in root seems to be a better way to refine the rights given.

To add on to what Valkhes says above, it's also recommend in the very document you linked under Daemon Security Considerations:

Try to avoid running your daemon with elevated privileges (for example, running it as root). If your daemon must run with elevated privileges, do not trust data received from non-privileged processes. Doing so might allow a local user to escalate their privileges.

The feedback assistant ticket number is 16838140

I see reference to a SessionCreate key in there for controlling the security context, is that useful in this situation?

Thanks!

Sure. But using a real user is problematic in the general case. The canonical example of this is FileVault 1, where the user’s home directory was stored an a disk image that could only be mounted with the user’s password. That would leave your daemon running without a home directory O-:

While FileVault 1 is a thing of the past, you can encounter similar problems if the user has a network home directory.

And that’s not the end of your problems. Consider the various file system permission mechanism described in On File System Permissions. Of those, only the first two, BSD and ACLs, are keyed off the current process’s user ID. If your daemon-running-as-a-real-user hits a MAC check — for example, it tries to access the Desktop folder — it’s completely unclear as to what’ll actually happen.

macOS is not a traditional Unix system. Its permission model is not gated solely by the traditional BSD execution context: UID, GID, and so on. This is not a new development (look at the date on TN2083!) but, as time goes by, more and more subsystems start to depend on the macOS-specific execution context. If you run in a mixed context then you will encounter weird problems.

Now, you could reasonably make an argument that a daemon running as a role account should be treated like a daemon when it comes to local network privacy. In fact, I’d probably agree with you (-: But my opinions don’t matter here, you need to make your case in Feedback Assistant.

However, that’s about role accounts. I don’t think it makes sense to file an ER for the real user case. Such daemons have many other problems besides local network privacy.

If your want to run background code as a real user, set it up as a launchd agent.

Thanks for that.

Unlikely. That just puts the job into its own unique session, which further separates it from the running-as-root global session that’s a known place where local network privacy stays out of your way.

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