Re: Sandboxing die.die.die
Re: Sandboxing die.die.die
- Subject: Re: Sandboxing die.die.die
- From: Laurent Daudelin <email@hidden>
- Date: Tue, 21 Aug 2012 21:46:11 -0700
On Aug 21, 2012, at 20:47, Graham Cox <email@hidden> wrote:
> Is sandboxing the MOST HATEFUL and useless API Apple have ever created? I can't think of a worse one in 30 years....
>
>
> Anyway ranting aside,
>
> I have a browser which allows the user to add folders to a source list and it then scans that folder for image files and displays them, including in any subfolders. The user can select subfolders to narrow down the list of images.
>
> When the app is quit, the list of folders is saved so that it can be restored next time. Previous to sandboxing, that was easy.
>
> Now, it's a seriously difficult proposition. Here's what I'm doing:
>
> The user adds folders to the browser using the standard NSOpenPanel, so the URL is automatically allowed by the sandbox, and can be bookmarked using a security scoped bookmark. I've added the entitlement to allow app-wide security-scoped bookmarks to work.
>
> Next session, the saved bookmarks are resolved and the browser UI restored. That now works (after much hair-pulling).
>
>
> Now, whenever a security-scoped URL must be accessed, you have to bracket that with -startAccessingSecurityScopedResource and -stopAccessingSecurityScopedResource, which in itself is painful because this method isn't available prior to 10.7.3, so you have to additionally check whether the URL responds to that selector, but no matter, I'm jumping through that flaming hoop OK. (I assume that my users on 10.7 earlier than 10.7.3 will just have to put up with the fact that none of this will work at all. Thanks Apple).
>
> The problem is that all of the files and folders INSIDE the folder created from the security bookmark are being disallowed by sandboxd despite doing this, presumably because those URLs don't contain the magic sauce that allows it to work - they are created by scanning the parent folder. Apparently URLs within a scoped folder don't inherit the ability to allow access using these methods. Fixing this is going to be extremely hard - a URL is supposed to encapsulate all of the information about the location of a file without reference to another URL elsewhere that happens to be the folder which contains it (and which does have the magic sauce).
>
> It is clearly impractical to save a security bookmark for every single file - there can be tens of thousands - and for the case of adding the folder using the NSOpenPanel it works OK, so surely there has to be a way to propagate the security access from a folder to all of the folders and files it contains?
>
> Or is this a use-case that once again has been overlooked in the unseemly rush to push sandboxing on us?
>
That's really bad news. I have a synchronization app on the App Store and I was hoping to update it with those security-scoped URLs but if it doesn't work for the content of folders, then I'm hosed.
Have you filed an enhancement request? It might well be a short sightseeing from Apple as the whole sandboxing enchilada seemed to be something that was quickly put together without much thought.
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/
Logiciels Nemesys Software email@hidden
_______________________________________________
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