The "Full Disk Access" authorization exists to facilitate the sort of thing you're describing. It disable the user privacy protection that's blocking access above. You can find the Full Disk Access setting in "System Settings > Privacy & Security > Privacy".
If I configure a LaunchDaemon using “SMAppService”, will the LaunchDaemon also share the “Full Disk Access” permission of the main app?
Two answers to that:
-
Yes. Part of the reason this API exists is that keeping the all of the app components inside the app bundle makes it easier to ensure that TCC permission can be correctly inherited, including FDA.
-
Qualified "but". Bugs are always possible, particularly with components that are executing outside the "standard" execution flow (like a LaunchDaemon running as root). If your app relies on FDA, then you should also consider how you'll handle access failures in a clean/graceful way. Keep in mind that there are many reasons access can fail (for example, Endpoint Security extensions or system external permission systems) beyond FDA.
"SMAppService" is supported only on macOS 13 and later. If I configure a LaunchDaemon using a plist on earlier macOS versions, can it still use the “Full Disk Access” permission?
First off, I would think carefully about exactly what system range you're willing/able to support, particularly in terms of when your product will actually ship. Choosing to support a broader system range can easily create a situation where older systems generate relatively little revenue (because older systems tend to install/buy far less software) and high support cost (because of the extra testing cost and difficulty of investigating problems on older systems).
Having said that, yes, you can grant FDA to a LaunchDaemon. My big recommendation here is that you package your daemon inside an app bundle instead of installing it as a "bare" executable. Putting that in more concrete terms, instead of having your launchd plist point to:
<path>/myexecutable
Put that executable inside an app bundle and have your launchd plist point to:
<path>/MySecurityApp.app/Contents/MacOS/myexecutable
Launchd itself won't care and never has*, as your plist simply points to slightly longer path (the executable inside the app bundle). However, using an app bundle means that you "fit" within the expectations the "rest" of the system has, minimizing the possibility of failure.
*Making sure this point is clear, launchd has NEVER required that executables follow any particular pattern or structure. Most of our daemon's do use "bare" executables, but that's PURELY because of how "we happened to do it" and not because bundling executables has (or ever had) any real downside.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
