Quinn "The Eskimo!"
August 19, 2016 at 1:42 AM
On 18 Aug 2016, at 17:58, James Bucanek <subscriber@gloaming.com> wrote:


Question: I now [have] a second system daemon (which I created to support XPC communications). This one is a bit special because its launchd properties include the <key>UserName</key> so the process is executes as the user that installed it.


OK, that statement is either incorrect or illustrates that we’re not using the same terminology.  A *launchd daemon* is system wide.  If you include the `UserName` property it’s started as that user; the only legitimate use case here is to supply a role account.  If you don’t include the `UserName` property, the daemon runs as root.

A *launch agent* is per user.  It runs as the user in whose context the agent was loaded.  If you include the `UserName` property, it’s ignored.

Does that make sense?  If so, is this “second system daemon” actually an agent?

It makes prefect sense. If you have an interest in understanding what I'm doing, I'll summarize it here. But you can skip this explanation as I think I've already found a solution.

I've created a service, aptly named the "switchboard," that I use to allow my various processes (agents, daemons, client apps, helpers, etc.) to form ad hoc XPC connections with each other. They do that by exchanging their NSXPCListenerEndpoint objects via the switchboard daemon.

The switchboard has to be in a Mach namespace that all processes (both user and root) from all sessions (system, user, and gui) can connect with via [NSXPCConnection initWithMachServiceName:...]. However, each switchboard service only serves a single user, so I really don't want it running as root or be accessible from just any process.

My solution is to install the switchboard as a system daemon (/Library/LaunchDaemons), so it's globally reachable. To tighten security, the daemon uses the <key>UserName</key> property so the daemon runs as that particular user, and the service rejects any XPC connections from a process with an effective UID of an unknown user.

So far, this seems to be working just great.

This is important because, in order to guarantee that you can act like the user, your code /must/ be running as an agent.  So a lot of the time you need two launchd jobs, one daemon providing system-wide functionality and one agent, loaded into each user’s context, that performs actions that can only be done in that context.

That is clear to me now. I've found that I can successfully run my metadata gathering process from any process created in the "user" domain (Background session) or "gui" domain (Aqua session). But everything that was launched/exec'd/spawned from the system domain doesn't work, no matter what its UID or EUID is.

My solution is to leverage a user agent that runs in either the user's "user" or "gui" domain, and use the switchboard to let my root process form a connection with it.
[1] There’s two problems with doing this:

* The set of context information is not documented to be exhaustive, so new stuff could be added in the future.

* The security context is now (since 10.7) tied to the audit session ID, and there’s no public API for switching that.

I have noticed the lack of a public API. ;) I did spend quit a bit of time looking for a way of either specifying the session ID for a new process, or switching sessions, but with a clearer understanding of the problem I think I now have a cleaner solution.

Cheers,

James