I’ve got a run of the mill Drag&Drop DMG installer. It works as expected when the drop target is /Applications. However I deliver plugins which I want to be copy to somewhere below /Library/Aplication Support/. Here too, everything works fine until I upload and download the dmg to my webserver. Now when dropping the plugins onto the target alias they just slide back. No error, no dialog asking for permissions, no nothing… just silently sliding back. And I haven’t the faintest idea how to address this. Would somebody please be my hero of the day and point me into the right direction, pretty please?
The plugins and the dmg are codesigned and notarized. They work as expected when moving them to the plugins folder directly. It’s only the alias that will not work. The alias btw. is a soft link created using ln - s.
Not sure this is the right category to post in. But it feels like it’s a probably a permission/entitlements issue.
Ooo ooo, I know this one! I recently researched this in depth as part of a DTS tech support incident.
Not sure this is the right category to post in.
Gatekeeper would be the best tag for this; I’ll move it over once I’m back in the office.
everything works fine until I upload and download the dmg to my webserver.
If you look in the system log I think you’ll see an entry like this:
type: error
time: 05:24:58.704737-0700
process: Finder
subsystem: com.apple.syspolicy
category: default
message: Drag to alias/symlink /Volumes/QDiskImage/Components, which targets /Library/Audio/Plug-Ins/Components, is disallowed by system policy
Note To see the paths involved I had to enable private data. For instructions on doing that, see Your Friend the System Log. And of course the paths will be different for your product; this was just my test disk image.
That is most definitely a smoking gun. When you drop an item on an alias or symlink the Finder consults our system policy module to decide whether to allow it or not. In this case that module has denied the request, logging the above log entry in the process.
This works for /Applications because that directory is on the system policy’s allowlist. Other directories are not on that allowlist, and so the request is denied [1].
Oh, and this policy only kicks in when the disk image is quarantined, which is why you only see the problem after the upload and download.
This policy is part of a security remediation, so it’s unlikely to change. In the long term I think the best fix for this problem is for Apple to not require that files be put in special places in order for them to function. This is how app extensions and system extensions work, and that’s great. And, and we’re extended this to other items with introduction of SMAppService in macOS 13 beta.
If you think that your plug-in type would benefit from that sort of facility, I encourage you to file an enhancement request along those lines.
In the interim, you have a couple of options:
-
Ship an installer package.
-
Educate your users that they must resolve the symlink first and then drag to that.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Just FYI, the current allowlist is:
ApplicationsApplications/UtilitiesDesktopLibrary/QuickLookLibrary/Screen SaversLibrary/PreferencePanesLibrary/CloudStorage/iCloud Drive/Desktop
in both / and ~. Obviously this is subject to change.
