[launchd-dev] Mysterious problem with [NSURL getResourceValue:forKey:error:]

Quinn "The Eskimo!" eskimo1 at apple.com
Fri Aug 19 01:42:14 PDT 2016


On 18 Aug 2016, at 17:58, James Bucanek <subscriber at gloaming.com> wrote:

> It's a real user. The sole purpose of this process is to collect user-perspective metadata for filesystem items (custom icon, localized display name, etc.) on behalf of a second process running as root.


In that case you need to make sure that this code is started in the correct user context; there’s no supported way to move code between contexts [1].

I have suggestions for how to start your code in the right context but I want to address the following first.

> 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?

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.

Share and Enjoy
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

[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.



More information about the launchd-dev mailing list