Monday, February 5, 2018 [Tweets] [Favorites]

Sandbox Limitation on Number of Files That Can Be Opened

Matteo Rattotti:

After loading a seemingly magic random number (around 3000/3200) of images the Sandbox will stop loading any more images. Any other operation that tries to load files from outside the container will fail.

The NSOpenPanel behave in a different way, it just won’t return more than the “magic random number” of images, and after that any attempt to use it will return zero files.

If the files are loaded from inside the container, they will all load as expected, but after reaching the “magic random number” files from outside the container can’t be loaded anymore.

I don’t think I’ve blogged about this before, but I’ve heard many reports of it, and as far as I’m aware it’s a longstanding issue that dates to the introduction of the com.apple.security.files.user-selected.read-only entitlement in macOS 10.7.3. Note that this is not about the number of files that can be open simultaneously. The undocumented limit applies even if you close your file descriptors.

A related issue is that I’ve been using OmniOutliner a lot more recently, and after a while it will complain that it doesn’t have permission to save my document. Indeed, it doesn’t think the file even exists. I can neither save nor close the document without force quitting. The Console log makes it look like this is related to security-scoped bookmarks, which are used to access files that are saved in the Documents folder rather than in the application’s container. The problem dates to at least 2014 and also affects OmniPlan and Numbers, adding to the likelihood that the bug is in the OS rather than apps. None of the workarounds described in the preceding forum links worked for me.

Update (2018-02-05): Peter Steinberger:

Security scoped URLs have many gotchas.

Update (2018-02-13): I also ran into a problem where Downcast couldn’t access any of the files in its sandbox container because of problems with security-scoped bookmarks. I had to delete everything and reset it.

2 Comments

[…] Previously: Sandbox Limitation on Number of Files That Can Be Opened. […]

A big issue for developers is that only Applications can be entitled to use NSOpenPanel. If you program a plug-in like a screensaver that runs within a system application like the screensaver service (in Catalina now called "legacyScreenSaver" / the legacy in the name did not implied much hope for future support) there is no way the plug-in can be entitled. Unfortunately Apple Engineers decided not to give the service the rights to let the user select some files with the NSOpenPanel. The only entitlement this service now has is to access its own and the system cache folder(and only a temporary exception as the entitlement name suggests com.apple.security.temporary-exception.files. absolute-path.read-only).

I think it should be not a too big security concern to let a user decide that an screensaver can access at least to a bunch of pictures or movies that a screensaver can show. A developer of a screensaver is pretty much screwed today with Catalina and only very view developers try to create strange workarounds with helper applications that can be entitled and that copy files through the very small sandbox hole in the cache folders even if the entitlement of the system service is only a temporary exception and nothing to rely on for future updates. All this looks like the sandboxing feature was rushed and is still unfinished.

It is discussed here for example:
https://forums.developer.apple.com/thread/119008
https://forums.developer.apple.com/thread/117136

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment