Accessing preferences in another app's sandbox - operation denied and NSAppDataUsageDescription never shows

Question

Created 2d

Replies 2

Boosts 0

Participants 2

macOS 27.0 beta 4

I have an installer app which needs to set a key/value inside a plist file during installation. This is for a screensaver that runs under the legacyScreensaver system, so the plist lives at:

~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver.x86-64/Data/Library/Preferences/com.foobar.plist

Although I can see the plist file in the Finder, my installer app can't read or write it, and the NSAppDataUsageDescription string is not shown, nor does the OS ask the user for permission.

Also, trying to do this via the Terminal app is also blocked (even using 'sudo'). I understand this is part of the new Golden Gate security system.

In Golden Gate, is there a legitimate way to accomplish this so it works like it did in macOS 26 and earlier?

I'd like my installer to request access, the NSAppDataUsageDescription string is shown, and the user can grant or deny permission.

Answer 1

DTS Engineer OP

Apple

18h

I don’t think there’s any reasonable way to achieve this specific goal )-: Recent versions of macOS have become increasingly strict about app and group container protection, as explained in the WWDC talks linked to by Trusted Execution Resources. This is just a further refinement of that overall goal.

IMO the correct long-term fix for this is for Apple to support app extensions based screen savers. If that happened, this problem would go away because you could store these preferences in an app group container that’s available both the screen saver appex and its container app. However, there’s no sign of that happening )-:

If you’d like to see that happen in the future, I encourage you to file an enhancement request describing this problem and any other problems you see caused by the legacy screen saver architecture. And please post your bug number, just for the record.

As to what you can do about this today, lemme start with question: How was your installer app previously writing this property list?

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

Answer 2

XMI OP

12h

Thanks, @DTS Engineer for your (as always) thoughtful comments.

I agree that using Appex format would be ideal. I submitted FB24013514 (under macOS / ExtensionKit / Suggestion) which I hope was the right category choice.

As for workarounds using legacyScreenSaver, I believe I have found one.

While it is true that a .saver running in the legacyScreenSaver sandbox can not read or write data from ~/Library/Preferences/com.foobar.plist

...it appears that it can read data from /Library/Preferences/com.foobar.plist (the shared Preferences location) with this code:

let val = CFPreferencesCopyValue(key as CFString, self.bundleID as CFString, kCFPreferencesAnyUser, kCFPreferencesAnyHost)

So a possible workaround is for the installer to write data to this location, which the screen saver can then read.

I'm not sure if this is a clever and legitimate workaround or a bad idea.

It seems unlikely to me that Apple would decide to restrict read-only access to /Library/Preferences in the future, but I don't have a great track record making these sorts of predictions.