OSX Sandboxing: security scoped bookmarks for all filesystem access

[RJ Skerry-Ryan]

Whenever we access files we must have permission from the OSX sandbox. To acquire permission from the user and store it we have to implement Security Scoped Bookmarks.

https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16

We need to keep track of paths that we have access to (maybe in SQlite) and when we try to access a resource we don't have access to yet, we have to ask the user for it.

[Owen Williams (ywwg)]

that there is a fantastic user experience. We can't even load files read-only outside the sandbox?

This stackoverflow thread talks about getting an exception:

http://stackoverflow.com/questions/10952225/is-there-any-way-to-give-my-sandboxed-mac-app-read-only-access-to-files-in-lib

https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html

If we are very specific about which folders we want to access, and only access them read-only, that might be enough for the App Store folks.

[RJ Skerry-Ryan (rryan)]

For reference we already got rejected for asking for com.apple.security.temporary-exception.files.absolute-path.read-write on /.

[RJ Skerry-Ryan (rryan)]

Here's a patch to Qt that automatically grabs a bookmark for all QFile's that are opened. I think they have to have been picked by the user via an open dialog though.

https://codereview.qt-project.org/#change,40779

We're going to have to come up with some kind of browse technique that's like:

1) User clicks on browse
2) We pop a dialog being like "pick the folder you want to browse"
3) Grab a security bookmark for the folder
4) normal browse anywhere within that folder and sub-folders

We may also have to either remove all quick links and have the user add them manually one by one.

We're also going to have to ask permission for the user's entire library on first run of the sandboxed version. We already ask for the library directory so that's going to be fine but migrating users over is going to be a PITA.

[Owen Williams (ywwg)]

So how about asking for read-only in Users/`whoami`/Music (or wherever the standard mixxx library location is)? I can understand why asking for read-write on the whole file system would be rejected.

[RJ Skerry-Ryan (rryan)]

We need read-write for Music (for recording) and that's a specific
entitlement: com.apple.security.assets.music.read-write

The user can pick an arbitrary library location so getting the Music folder
doesn't save us. We need to fix this bug or radically change the way Mixxx
works :(.

On Tue, Dec 3, 2013 at 11:32 AM, Owen Williams <email address hidden> wrote:

> So how about asking for read-only in Users/`whoami`/Music (or wherever
> the standard mixxx library location is)? I can understand why asking
> for read-write on the whole file system would be rejected.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1257340
>
> Title:
> OSX Sandboxing: security scoped bookmarks for all filesystem access
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1257340/+subscriptions
>

[Max Linke (max-linke)]

When and to what folder do we need write access? If it is just the recording feature then we can just ask about that one folder. Then there is also our config folder. With all the other files I can think of we are just reading.

[RJ Skerry-Ryan (rryan)]

You still have to do this for read access too. To support tag writing we
should make our bookmark read/write anyway though.

On Tue, Dec 3, 2013 at 2:07 PM, Max Linke <email address hidden>wrote:

> When and to what folder do we need write access? If it is just the
> recording feature then we can just ask about that one folder. Then there
> is also our config folder. With all the other files I can think of we
> are just reading.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1257340
>
> Title:
> OSX Sandboxing: security scoped bookmarks for all filesystem access
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1257340/+subscriptions
>

[Max Linke (max-linke)]

Can't we automatically assume the user wants mixxx to read/write in any
folder that he sets as the library-folder (I know that won't work for
the browse feature)? How do other music apps in the App-Store handle
this in the UI?

On Tue, 2013-12-03 at 19:18 +0000, RJ Ryan wrote:
> You still have to do this for read access too. To support tag writing we
> should make our bookmark read/write anyway though.
>
>
> On Tue, Dec 3, 2013 at 2:07 PM, Max Linke <email address hidden>wrote:
>
> > When and to what folder do we need write access? If it is just the
> > recording feature then we can just ask about that one folder. Then there
> > is also our config folder. With all the other files I can think of we
> > are just reading.
> >
> > --
> > You received this bug notification because you are a member of Mixxx
> > Development Team, which is subscribed to Mixxx.
> > https://bugs.launchpad.net/bugs/1257340
> >
> > Title:
> > OSX Sandboxing: security scoped bookmarks for all filesystem access
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/mixxx/+bug/1257340/+subscriptions
> >
>

[RJ Skerry-Ryan (rryan)]

Yea, for new users the solution to this bug would be to make a security bookmark when the user picks their library folder.

For all existing users on the Mac App Store, we need to migrate them by doing some annoying "please select the root folder of your drive and hit OK to grant Mixxx permission to use that folder". And any other time Mixxx wants to read a file (e.g. a file referenced by the iTunes library that isn't in the set of folders we already bookmarked) we have to do this as well.

[Max Linke (max-linke)]

It is not an option to check which folder is set in the database and
then make a security bookmark for that one? Do we really have to ask
them about permission with a UI or can we just make security bookmarks
based on the assumption that if a user wants to play any song from his
iTunes library he implicitly grants us read permissions?

So is the UI required by apple or just that we set these bookmarks?

On Tue, 2013-12-03 at 20:23 +0000, RJ Ryan wrote:
> Yea, for new users the solution to this bug would be to make a security
> bookmark when the user picks their library folder.
>
> For all existing users on the Mac App Store, we need to migrate them by
> doing some annoying "please select the root folder of your drive and hit
> OK to grant Mixxx permission to use that folder". And any other time
> Mixxx wants to read a file (e.g. a file referenced by the iTunes library
> that isn't in the set of folders we already bookmarked) we have to do
> this as well.
>

[RJ Skerry-Ryan (rryan)]

Yea, the only way to get a security bookmark is if the user explicitly OKs
an NSOpenPanel (which QFileDialog uses).

On Tue, Dec 3, 2013 at 3:38 PM, Max Linke <email address hidden>wrote:

> It is not an option to check which folder is set in the database and
> then make a security bookmark for that one? Do we really have to ask
> them about permission with a UI or can we just make security bookmarks
> based on the assumption that if a user wants to play any song from his
> iTunes library he implicitly grants us read permissions?
>
> So is the UI required by apple or just that we set these bookmarks?
>
> On Tue, 2013-12-03 at 20:23 +0000, RJ Ryan wrote:
> > Yea, for new users the solution to this bug would be to make a security
> > bookmark when the user picks their library folder.
> >
> > For all existing users on the Mac App Store, we need to migrate them by
> > doing some annoying "please select the root folder of your drive and hit
> > OK to grant Mixxx permission to use that folder". And any other time
> > Mixxx wants to read a file (e.g. a file referenced by the iTunes library
> > that isn't in the set of folders we already bookmarked) we have to do
> > this as well.
> >
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1257340
>
> Title:
> OSX Sandboxing: security scoped bookmarks for all filesystem access
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1257340/+subscriptions
>

[Owen Williams (ywwg)]

So is permission per-file or per-folder? It sounds like it may be whichever the user explicitly allows. Maybe we can detect that the user is accessing files on a mounted device (/Volumes/*) and if so, ask permission to read/write the whole volume. That way they wouldn't be prompted for every single file on a flash drive.

Similarly, you mentioned the quick bookmarks being an issue -- we could just ask permission the first time they click on a bookmark.

I would love to find out how Serato deals with this situation!

[RJ Skerry-Ryan (rryan)]

Serato is not on the app store :). VDJ and Cross are though. I'm not sure
if they've updated since sandboxing became required.

On Tue, Dec 3, 2013 at 4:00 PM, Owen Williams <email address hidden> wrote:

> So is permission per-file or per-folder? It sounds like it may be
> whichever the user explicitly allows. Maybe we can detect that the user
> is accessing files on a mounted device (/Volumes/*) and if so, ask
> permission to read/write the whole volume. That way they wouldn't be
> prompted for every single file on a flash drive.
>
> Similarly, you mentioned the quick bookmarks being an issue -- we could
> just ask permission the first time they click on a bookmark.
>
> I would love to find out how Serato deals with this situation!
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1257340
>
> Title:
> OSX Sandboxing: security scoped bookmarks for all filesystem access
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1257340/+subscriptions
>

[RJ Skerry-Ryan (rryan)]

https://github.com/mixxxdj/mixxx/pull/169

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7208