Aperture 3.4, Sandboxing, and FlickrExport
Aperture 3.4 is now sandboxed (via Fraser Speirs). This initially caused some problems because it did not migrate my FlickrExport preferences file from:
~/Library/Preferences/com.connectedflow.flickrexportaperture.plist
to:
~/Library/Containers/com.apple.Aperture/Data/Library/Preferences/com.connectedflow.flickrexportaperture.plist
FlickrExport thus didn’t find its preferences. It lost its Flickr API token, thought I hadn’t purchased, and lost my preferences for which keywords to hide. I re-added these, but it wasn’t until after I’d uploaded a set that I realized I had forgotten to re-enable the preferences to save the Flickr ID and URL back to Aperture. Thus, the options to replace photos and update metadata didn’t work until I’d copied and pasted all the photo IDs from the Web site. In retrospect, I should have moved the preferences file to the new location right after updating Aperture. Of course, I would have if I had known then that it was sandboxed.
Knowing a bit about how Aperture works, I wondered how some of its features could be made to work in the App Sandbox. The answer is that Apple plays by different rules. For example, my copy of Aperture isn’t from the Mac App Store, but it has access to iCloud. Third-party applications need to use clunky UI workarounds and security-scoped bookmarks to access files outside of a document package; Apple simply gives Aperture a com.apple.security.temporary-exception.files.absolute-path.read-write entitlement with value /, i.e. read-write access to the entire filesystem. Aperture also makes use of com.apple.security.temporary-exception.sbpl, which Daniel Jalkut noted is the Big Red Button.
Also note that, aside from “com.apple.PhotoApps.AVCHDConverter.xpc” (presumably a codec), Aperture does not use XPC services for privilege separation. The main Aperture application has full hard drive access, as well as being a network client, a network server, and all the rest.
With so many entitlements and temporary exceptions, it doesn’t seem like “sandboxing” Aperture in this way provides many security benefits. Aperture isn’t protected from bugs in itself. And a malicious plug-in could read my address book (or, indeed, any file on my hard drive) and upload it over the network. However, it does restrict what plug-ins can do a bit. For example, Aperture has temporary exceptions for sending Apple events to Mail and iTunes; other event targets are forbidden. This means, for example, that you can no longer write a plug-in that integrates Aperture with Photoshop or Acorn.
Here’s the full list of Aperture 3.4 entitlements:
icarus$ codesign -d --entitlements - /Applications/Aperture.app|bbedit
Executable=/Applications/Aperture.app/Contents/MacOS/Aperture
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.application-identifier</key>
<string>F9L2L89K5X.com.apple.Aperture</string>
<key>com.apple.private.icloud-account-access</key>
<true/>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.assets.movies.read-write</key>
<true/>
<key>com.apple.security.assets.music.read-only</key>
<true/>
<key>com.apple.security.assets.pictures.read-write</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.library-repair.extensions</key>
<array>
<string>photolibrary</string>
<string>aplibrary</string>
</array>
<key>com.apple.security.library-repair.ostype</key>
<array>
<string>iPlb</string>
</array>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.network.server</key>
<true/>
<key>com.apple.security.personal-information.addressbook</key>
<true/>
<key>com.apple.security.print</key>
<true/>
<key>com.apple.security.temporary-exception.apple-events</key>
<array>
<string>com.apple.mail</string>
<string>com.apple.itunes</string>
</array>
<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<string>/</string>
<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
<array>
<string>com.apple.photostream-agent</string>
</array>
<key>com.apple.security.temporary-exception.mach-lookup.global-name:before:10.8</key>
<array>
<string>com.apple.AOSNotification-FMM</string>
</array>
<key>com.apple.security.temporary-exception.sbpl</key>
<string>
(begin
(allow file-search)
(allow ipc-posix-sem)
(allow system-fsctl))
</string>
<key>com.apple.security.temporary-exception.shared-preference.read-only</key>
<array>
<string>com.apple.iPhoto</string>
</array>
<key>com.apple.security.temporary-exception.shared-preference.read-write</key>
<array>
<string>com.apple.Aperture</string>
<string>com.apple.iApps</string>
<string>com.apple.iLifePhotoStream</string>
<string>com.apple.iLifeAssetManagement.agent</string>
<string>com.apple.iLifeAssetManagement.crash</string>
<string>com.apple.iLifePhotoStream.importstatus</string>
<string>MobileMeAccounts</string>
<string>com.apple.ImageCapture2</string>
<string>com.apple.mcxprinting</string>
</array>
</dict>
</plist>
14 Comments RSS · Twitter
Apertures Flickr support is a sad thing, it never works the way I expect it to work so I've given up on it. FlickrExport is the best way to upload photos from Aperture to one ore more Flickr accounts.
@Greg What JEM said. I like Aperture in general, but I just don’t trust its built-in Flickr support.
[...] Link. Big undocumented change. by jgordon on September 23, 2012 • Permalink Posted in share Tagged s [...]
Wow, excellent digging. I started to respond with a comment, but my comment quickly expanded to a full blog post. So, you can find my response here: http://www.c-had.com/does-this-count .
@Chad Thanks for looking at this in more detail. I suppose you could win the reviewer lottery, but from what I’ve heard it’s essentially impossible for a third-party app to get approved with read-write access to “/”, even if there’s no other workaround. And, as you note, even with this broad access Apple still had to use entitlements that don’t even exist for third-party developers. Thanks also for mentioning the “:before:10.8” suffix, which I noticed but forgot to write about before posting this.
Seems like class action lawsuit material to me. Sure feels a lot like what Microsoft got in trouble for in the '90s....
[...] UPDATE 2: It looks like sandboxing is so restrictive, that Apple is using private exceptions and security scoping in their apps that aren’t available to developers. http://mjtsai.com/blog/2012/09/23/aperture-3-4-sandboxing-and-flickrexport/ [...]
Oh, *that's* why my Aperture-to-Gallery plugin stopped working recently! Thank you, thank you!
I thought it might have something to do with Übermind ceasing support of all their plugins -- that didn't quite make sense, but it seemed unlikely to me that a move from 3.3 to 3.4 would break plugins. I guess not! Moving all the preferences from one location to the other did the trick for me. I don't know how I would have ever found out about this if not for following you via RSS!
I corrected the text in the Aperture 3.4 update and uploaded it: http://cl.ly/JnSi
[...] and management software. Though in theory sandboxed like everything else in the App Store, Apple seems to have granted itself blanket entitlements that let Aperture perform all the tasks it used to [...]
