Re: Sandboxing die.die.die
Re: Sandboxing die.die.die
- Subject: Re: Sandboxing die.die.die
- From: Graham Cox <email@hidden>
- Date: Thu, 23 Aug 2012 12:14:26 +1000
On 23/08/2012, at 9:37 AM, Graham Cox <email@hidden> wrote:
> Trying to work around this is proving impossible with the current sandbox implementation - there are too many opaque hacks in the system that mean you cannot trust the URLs you get from anywhere to actually point to the right place, and you also have to hard-code paths in your entitlements which are extremely fragile under both localisation and system updates. (For example, if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that location changes, or is named differently, my app stops working. Note the name of the iPhoto Library did subtly change between 10.7 and 10.8 - the space is a different unicode character now).
Well, I spoke too soon, and have actually solved this problem. Whether it proves to be robust I can't say, but it wouldn't seem to be any worse than our un-sandboxed app in that respect.
Turns out the problem I was having with this is because of the behaviour of [NSURL fileURLWithPath:isDirectory:].
When I passed the path to the iPhoto database file (~/Pictures/iPhoto Library/Album.xml) the resulting URL was bizarrely altered to point to some non-existent path within my sandbox. In fact it looks like a bug because it ended up concatenating 'file://' somewhere in the middle of the path which makes no sense. Instead, I used [NSURL URLWithString:] and it works correctly.
I've also had to rev a fair bit of my code to work with URLs rather than paths, but that was a legacy from before URLs were more commonly used so that's not a sandboxing issue per se, but using URLs works with sandboxing whereas paths do not always it seems. I've been meaning to update this legacy code for a while, but while it continued to work had no real incentive to do it.
Because the iPhoto Library lives inside ~/Pictures, and there is a general entitlement for that folder, I no longer need a special temporary exception for the iPhoto Library, so the hard-coded paths issue goes away, as long as iPhoto Library remains in this location. I look up the actual name by peeking at iApps preferences and I still need a temporary entitlement for that, so I'm still at the mercy of Apple changes to these things, but no more so than before.
The other aspect to the general problem I was having, that of managing to resolve security-scoped bookmarks across sessions, I solved yesterday. Turns out the issue there is that you need to call the -startAccessingSecurityScopedResource after resolving the bookmark and leave it in that state until you are completely done with the folder (in my case that's only when the app quits).
I get an exception logged when dragging and dropping, but oddly it doesn't seem to cause any problems - D&D still works fine: Anyone any thoughts on this:
Artboard(70831) deny file-issue-extension /Users/grahamcox/Pictures/IMG_0899.JPG
OS Version: Mac OS X 10.8 (12A269)
Report Version: 8
Thread 0:
0 libsystem_kernel.dylib 0x0000000103f99efe __mac_syscall + 10
1 libsystem_sandbox.dylib 0x000000010401e4fe sandbox_issue_fs_rw_extension + 32
2 CoreFoundation 0x00000001013b77e2 __CFPasteboardIssueSandboxExtensionForPath + 130
3 CoreFoundation 0x00000001013b74e6 __CFPasteboardIssueSandboxExtensionForFileURL + 150
4 CoreFoundation 0x00000001013838b7 __CFPasteboardSetData + 1287
5 CoreFoundation 0x000000010138333e CFPasteboardSetData + 446
6 AppKit 0x0000000101bb774d -[NSPasteboard _setData:forType:index:usesPboardTypes:] + 376
7 AppKit 0x0000000101bb9020 -[NSPasteboard writeObjects:] + 1219
8 Artboard 0x000000010009b8f1 -[GCMediaBrowserController imageBrowser:writeItemsAtIndexes:toPasteboard:] + 161 (GCMediaBrowserController.m:636)
9 ImageKit 0x000000010a19a6b6 -[IKImageBrowserView(ImageBrowserDragNDropInternal) startDragNDropWithEvent:itemIndexes:] + 616
10 ImageKit 0x000000010a19f949 -[IKImageBrowserView(ImageBrowserEvents) mouseDragged:] + 1235
So unless any further issues are uncovered by testing with sandboxing, it looks like my app will now be able to adopt it with no loss of functionality, which is a huge relief.
I still think the general issues surrounding the sandboxing implementation are worth discussion though.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden