Our app attempts to install a PDF workflow in ~/Library/PDF Services but on a clean install of newer macOS versions, that directory no longer exists. Attempting to create the folder requires prompting for user permission to access the ~/Library directory and then prompting the user to access the newly created ~/Library/PDF Services directory. This is annoying and awkward.
Creating the PDF Service in the sandbox Library directory does nothing useful since the PDF workflow does not show up in the PDF workflow list in the print dialog.
We would like to create both directories in one step, or have the OS create the folder like it used to.
Is there an entitlement that will allow our app access to the ~/Library directory without requiring Full Disk Access?
Is there a way to have the OS create a symlink in ~/Library for the PDF Services directory that works with macOS 14 and later?
Our app attempts to install a PDF workflow in ~/Library/PDF Services, but on a clean install of newer macOS versions, that directory no longer exists.
Please file a bug on this and then post the bug number back here. It won't change anything about your immediate situation[1], but the nature of the sandbox environment means that we should probably be more aware of the broader consequences this kind of directory removal can have.
Attempting to create the folder requires prompting for user permission to access the ~/Library directory and then prompting the user to access the newly created ~/Library/PDF Services directory. This is annoying and awkward. ... We would like to create both directories in one step.
So, in terms of direct creation, I can see a few options that should work.
-
If you present a save panel that targets ~/Library/PDF Services, then you should be able to directly create the folder in one pass. That flow is a little weird/awkward since you'll need to force the user to approve that exact save location, but I'd otherwise expect this to work fine. Note that while it may seem strange to use the save panel to create a directory, that’s exactly what apps that use file packages do when they save.
-
If the user has approved access to "~/Library/", then I wouldn't expect you to need the second prompt. A security-scoped bookmark would let you preserve access into the future (though that's quite broad access), but, more usefully, you should be able to create the new directory and then create a security-scoped bookmark to that new directory. Have you tried this?
That leads to here:
Is there an entitlement that will allow our app access to the ~/Library directory without requiring Full Disk Access?
The other option here would be to use the home relative temporary file access entitlement to grant your app direct access to that directory. I haven't specifically tested it, but I think the value "/Library/PDF Services" would include the right to create the directory. I don't know whether or not this would be allowed on the Mac App Store, but don't see any issue with using this outside the App Store.
One comment on the "temporary entitlement" set. These entitlements were originally named that way to note that they were not considered the "final" solution to these issues and that apps should consider alternative implementations and/or be prepared to adopt different entitlements in the future.
However, particularly with the file access entitlements, that doesn't necessarily mean the entitlement is likely removed anytime soon. The issue with the file access entitlements is that these act as a kind of "escape hatch", giving us a way to immediately resolve any access issue an app runs into without requiring new API or system-level changes. Similarly, within that role, it's hard to see how we'd make an entitlement that provides the same general ability ("grant access to a path we can't predict") that worked any differently than the existing entitlement. Lastly, the security implications of this entitlement are narrower than they might seem. The entitlement allows access through the App Sandbox restrictions, but the system has multiple access control systems (see this forum post for more details) which this entitlement has no effect on.
[1] Even if we start shipping with this directory again, you'd still have many users missing the directory.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
