Entitlement to write preference that includes a device specific identifier

Since the macOS 14.2 update, services installed with SMAppService are required to be sandboxed when the main app is sandboxed as well (113037504).

I had developed a daemon to communicate with the pmset interface, as that requires root privileges to make changes. Since the macOS 14.2 this daemon executable has to be sandboxed as well if I want my main app to be sandboxed.

When sandboxing the daemon, it requires a temporary exception entitlement as the pmset command writes to one of the following two preference located in /Library/Preferences/:

  • com.apple.PowerManagement.plist
  • com.apple.PowerManagement.{UUID}.plist

The specific command I use writes to the latter, which includes some specific UUID, that is specific to that device.

When I use the: com.apple.security.temporary-exception.shared-preference.read-write entitlement with com.apple.PowerManagement.0000 where 0000 is the exact UUID string as on my Mac, the daemon is able successfully use the pmset command. This results however in that on other user devices it would not work as the UUID in the preference name would be different.

When I try setting it to a wildcard variation such as com.apple.PowerManagement.*, the command doesn't run anymore as this format for the exception entitlement seems to be unsupported.

My question is now, is there any way to get an exception entitlement which accounts for the unique identifier or is that impossible and must I disable the sandbox altogether?

(as I have to use a daemon, I am not developing for the Mac App Store and a sandbox isn't strictly necessary so it wouldn't break my app. Its more I would prefer to use sandboxing if possible)

Thanks in advance!

For reference, this is the error I get when the entitlement is set incorrectly or not set:

rejecting write of key(s) AC Power in { com.apple.PowerManagement.0000, kCFPreferencesAnyUser, kCFPreferencesCurrentHost, /Library/Preferences/com.apple.PowerManagement.0000.plist, managed: 0 } from process 15694 (pmset) because setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access

Accepted Reply

Since the macOS 14.2 update, services installed with SMAppService are required to be sandboxed when the main app is sandboxed as well (113037504).

I’m still researching the fallout from that change but, for the moment, and for your specific app, I think the best option is to simply ship your app un-sandboxed.

Share and Enjoy

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

Replies

Since the macOS 14.2 update, services installed with SMAppService are required to be sandboxed when the main app is sandboxed as well (113037504).

I’m still researching the fallout from that change but, for the moment, and for your specific app, I think the best option is to simply ship your app un-sandboxed.

Share and Enjoy

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