4 ms·

Some points of clarification to eliminate some FUD, especially around plugins: - Signed and sandboxed applications are not prevented from using plugins. No cod

Some points of clarification to eliminate some FUD, especially around plugins: - Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space. - Plugins do not need to exist within the app's bundle. Plugins don't even necessarily need to exist within a sandboxed app's container, if that app requests an exception to read its plugin directory (e.g. ~/L/Application Support/MyApp/Plug-ins). - Plugins can be signed and distributed independently from their host app. - Calling out restricted Thunderbolt access is a misnomer. AFAIK, there is no public Thunderbolt API now and as Thunderbolt is largely PCI Express + DisplayPort, any kind of access would have required kexts anyway. As kernel extensions already aren't allowed on the App Store, this isn't (just) a sandbox restriction. - Bluetooth devices can likely be accessed via AppleBluetoothUSBHCIController, which provides a USB HCI interface to any compatible BT devices. - You can read/write files in a known location on a network disk (or any disk) if you simply ask for permission once per launch. In fact, if you opt-in to auto termination, that user-granted entitlement will persist across most app relaunches, as long as the app's serialized state is preserved[1]. (And if you filed a radar requesting such a feature, it's very possible Apple would find a way to persist that user-granted entitlement across all app relaunches.) Regarding other points, it is true that Firewire access is restricted, as is general filesystem access and frame buffer access. Likewise, a sandboxed app is prevented from sending Apple Events to arbitrary applications, breaking a good bit of IPC. It's fair to complain about these restrictions (some of them affect my apps, and working around them will not be simple and may require removing popular features), but please don't cloud the issue with misinformation. [1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-and-file-references.html#308916 http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...

pavlov 15y ago
- Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. Really? That's good news if true. Got a reference for that? In any case, since loading plugins would be subject to the same restrictions as other file access, the app can't maintain persistently accessible references to the plugin files. The app would have to ask the user to manually pick each plugin using a file dialog, each time the app is run. This kind of "manually-aided binary loading" isn't really a plugin API anymore. Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space. Please elaborate. I still don't see how XPC can be used to implement a plugin architecture, assuming the Apple documentation is correct in stating that XPC services need to be located inside the main application bundle in order to be loaded. Re: Thunderbolt -- the problem here is that even if a kernel extension driver is already installed, a sandboxed app can't access it. (The example case in my mind would be my own video capture app: it's got direct support for devices by Blackmagic Design, including their new Thunderbolt-based units. I'm using the vendor's API for this. If I were to sandbox this app, it would have to lose this functionality.) [Edited this reply to add more details.]
- ryannielsen 15y ago
  > - Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. > Really? That's good news if true. Got a reference for that? https://devforums.apple.com/thread/108004 https://devforums.apple.com/thread/108004 (Apologies to anyone not registered as an Apple developer.) > Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space. > Please elaborate. I still don't see how XPC can be used to implement a plugin architecture, assuming the Apple documentation is correct in stating that XPC services need to be located inside the main application bundle in order to be loaded. The app can modify its bundle, so that's not the problem. While I haven't actually tried this myself, there's nothing theroetically preventing the app from copying a service into its Contents/XPCServices directory in response to some user action that makes that service available to the sandboxed app (e.g. they double clicked a file that's of a type registered by the app, or they invoked an open panel within the app somehow). The bigger problems, and ones that I can't find solid docs on are: 1) Does the service's signature need to match the parent app's signature? The docs actually indicate the service might not even need to be signed. 2) Can the app easily enumerate services, to discover new ones? Presumably, this should be possible but, again, I've never tried it myself. In the end, it may well be that XPC isn't an option for 3rd party out-of-process plugins. In process plugins are, as noted above, not a problem though. > Re: Thunderbolt -- the problem here is that even if a kernel extension driver is already installed, a sandboxed app can't access it. (The example case in my mind would be my own video capture app: it's got direct support for devices by Blackmagic Design, including their new Thunderbolt-based units. I'm using the vendor's API for this. If I were to sandbox this app, it would have to lose this functionality.) Ah, gotcha. I'm a little surprised to hear about that restriction, as I was the BT and Firewire restrictions. I'd have expected all of those to work, as long as your app was only using user-space APIs. Is the mach port lookup restriction what kills these? Have you contacted WWDR? We've got a WWDR contact that has been very helpful and proactive.
ryannielsen 15y ago
It also appears that screenshots in in fact allowed. According to Gus Mueller, author of Acorn, the app linked to in the article when screenshots are mentioned: https://twitter.com/ccgus/status/132182964766375937 https://twitter.com/ccgus/status/132182964766375937 And confirmed by another Mac dev: https://twitter.com/gte/status/132183576841175041 https://twitter.com/gte/status/132183576841175041

pavlov 15y ago

- Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. Really? That's good news if true. Got a reference for that? In any case, since loading plugins would be subject to the same restrictions as other file access, the app can't maintain persistently accessible references to the plugin files. The app would have to ask the user to manually pick each plugin using a file dialog, each time the app is run. This kind of "manually-aided binary loading" isn't really a plugin API anymore. Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space. Please elaborate. I still don't see how XPC can be used to implement a plugin architecture, assuming the Apple documentation is correct in stating that XPC services need to be located inside the main application bundle in order to be loaded. Re: Thunderbolt -- the problem here is that even if a kernel extension driver is already installed, a sandboxed app can't access it. (The example case in my mind would be my own video capture app: it's got direct support for devices by Blackmagic Design, including their new Thunderbolt-based units. I'm using the vendor's API for this. If I were to sandbox this app, it would have to lose this functionality.) [Edited this reply to add more details.]

ryannielsen 15y ago
> - Signed and sandboxed applications are not prevented from using plugins. No code loading restrictions are placed upon such processes. > Really? That's good news if true. Got a reference for that? https://devforums.apple.com/thread/108004 https://devforums.apple.com/thread/108004 (Apologies to anyone not registered as an Apple developer.) > Furthermore, Lion-only apps could employ an XPC based plugin architecture and entirely avoid loading code into their address space. > Please elaborate. I still don't see how XPC can be used to implement a plugin architecture, assuming the Apple documentation is correct in stating that XPC services need to be located inside the main application bundle in order to be loaded. The app can modify its bundle, so that's not the problem. While I haven't actually tried this myself, there's nothing theroetically preventing the app from copying a service into its Contents/XPCServices directory in response to some user action that makes that service available to the sandboxed app (e.g. they double clicked a file that's of a type registered by the app, or they invoked an open panel within the app somehow). The bigger problems, and ones that I can't find solid docs on are: 1) Does the service's signature need to match the parent app's signature? The docs actually indicate the service might not even need to be signed. 2) Can the app easily enumerate services, to discover new ones? Presumably, this should be possible but, again, I've never tried it myself. In the end, it may well be that XPC isn't an option for 3rd party out-of-process plugins. In process plugins are, as noted above, not a problem though. > Re: Thunderbolt -- the problem here is that even if a kernel extension driver is already installed, a sandboxed app can't access it. (The example case in my mind would be my own video capture app: it's got direct support for devices by Blackmagic Design, including their new Thunderbolt-based units. I'm using the vendor's API for this. If I were to sandbox this app, it would have to lose this functionality.) Ah, gotcha. I'm a little surprised to hear about that restriction, as I was the BT and Firewire restrictions. I'd have expected all of those to work, as long as your app was only using user-space APIs. Is the mach port lookup restriction what kills these? Have you contacted WWDR? We've got a WWDR contact that has been very helpful and proactive.

ryannielsen 15y ago

It also appears that screenshots in in fact allowed. According to Gus Mueller, author of Acorn, the app linked to in the article when screenshots are mentioned: https://twitter.com/ccgus/status/132182964766375937 https://twitter.com/ccgus/status/132182964766375937 And confirmed by another Mac dev: https://twitter.com/gte/status/132183576841175041 https://twitter.com/gte/status/132183576841175041