- 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.)
> 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.
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.]