open() failed: Operation not permitted

[dchohfi]

Using Realm (0.98.1)

Facing following crash, no specific device, happening on all iPhones. iOS 8+.

After calling +[RLMRealm defaultRealm] got the stacktrace:

Thread : Fatal Exception: RLMException
0  CoreFoundation                 0x180f65900 __exceptionPreprocess
1  libobjc.A.dylib                0x1805d3f80 objc_exception_throw
2  app                            0x100422f0c RLMSetErrorOrThrow(NSError*, NSError* __autoreleasing*) (RLMUtil.mm:314)
3  app                            0x100415714 RLMRealmTranslateException(NSError* __autoreleasing*) (RLMRealm.mm:273)
4  app                            0x1004159e4 +[RLMRealm openSharedRealm:error:] (RLMRealm.mm:282)
5  app                            0x100415d60 +[RLMRealm realmWithConfiguration:error:] (memory:4212)
6  app                            0x100414f74 +[RLMRealm defaultRealm] (RLMRealm.mm:162)

Realm configuration initialized on app creation, before everything.
All crashes seems to be happening after a push notification tries to awake the app.
Any idea on why this is happening?

[dchohfi]

Seems to be duplicated as #1874, but the solution doesn't seems to be the best, something better to do?

[jpsim]

@dchohfi could you please share the exception message? Initializing a Realm can fail for a number of reasons. See our docs on Error Handling for details.

[dchohfi]

Hey @jpsim thank you for the fast reply, it seems to be related to iOS file protection defined by the application.

Now I'm removing the file protection on all realm files as you described here:
#1571 (comment)

Just curious to know when I should be calling this?
Before or after calling the first +[RLMRealm defaultRealm]?

[jpsim]

The file protection attributes can only be set on existing files, so you need to do that after initially opening the Realm file.

[dchohfi]

@jpsim cool, makes sense. Do you think it's appropriate to have a single method on realm configuration to do that for us? Also doing the lazy creation logic. PR's are accepted? Or this is like that by design?

[jpsim]

I think it's worth improving this use case, and others like it. We could expose a fileAttributes property to RLMRealmConfiguration that would apply attributes to all Realm-related files.

Another option would be to add a getter to RLMRealmConfiguration that would return all auxiliary file paths. This would be more flexible, also allowing other operations on all Realm files like moving or deleting them.

I'm curious to hear what @tgoyne and @bdash would think of that.

[dchohfi]

@jpsim cool, just curious to know how the auxiliary files are created and if they are deleted and created again. If they are, do I need to change the NSFileProtectionKey every time? And how are we notified about those files creation?

[tgoyne]

The file protection attributes have to be set on the containing directory and not the individual files, as some of the files are created lazily and thus otherwise can't be created if the device is already locked when the first commit is made.

[dchohfi]

@tgoyne but this could easily be fixed with something like @jpsim said, a fileAttributes attribute that will replicate the logic to all the realm files created. Without needing to know about how realm create files. Or not?

[tgoyne]

Realm needs to be able to create files in the same directory as the Realm file while the device is locked if you want to be able to use the Realm file while the device is locked. Creating files while the device is locked requires that the containing directory have file protection disabled.

[dchohfi]

@tgoyne so we don't actually need to remove file protections on auxiliary file paths if I have removed on the containing directory?

[tgoyne]

Yes, files inherit their default file protection settings from the containing directory.

[TimOliver]

From the sound of it, the immediate fix for this would be to simply set the file attributes property of the parent directory. I might check our docs to make sure this is highlighted.

I like the idea of adding a file attributes property to RLMRealmConfiguration to handle the protection properties of all files related to a Realm instance. It should be possible on the NSFileManager level to create new files even if the device is locked.

@dchohfi Did you end up getting it working in the end?

[dchohfi]

Hey @TimOliver, honestly saying? I don't know if it's fixed or not, the crash was related to file protection that was activated on the app. But how we discovered that was tricky.

We found a crash on crashlytics during beta release and had to identify who was the person who had that, he said that never faced any crash during the beta and we realised that was something related to the notification that awakes the app in background.

Now we added the flags and released a new version following what we spoke in this thread. And wait a bit to see if fixed or not, as replicate is quite difficult.

That is why I think some attribute on RLMRealmConfiguration or even a warning (if possible) saying that the file protection is activated, just to show a straightforward solution to the problem, could be easier for devs.

[dchohfi]

Also, as you guys recommend to remove file protection from realm files, could be this the default behaviour and let the user change if needed?

[mrackwitz]

@TimOliver:

It should be possible on the NSFileManager level to create new files even if the device is locked.

I don't think that this is actually possible. If the directory is protected, it should be encrypted when the device is locked. If NSFileManager could bypass that, this would be a security loophole.

I like the idea of adding a file attributes property to RLMRealmConfiguration to handle the protection properties of all files related to a Realm instance.

Setting the default file attributes for newly created files won't be enough though. I think we would need to check the parent directory instead. One problem here might be that there could be likely any arbitrary other user files adjacent to the default Realm path, which should be better protected in some cases. So just removing the protection by default might not be the best solution. (Perhaps we should think about scoping the default Realm path by another directory element, so that it is easier to workaround this case?)
We could also have a property backgroundAccessRequired on RLMRealmConfiguration, disabled by default, but when enabled Realm would fail gracefully directly on first open with instructions how to make sure that the parent directory is not protected. As this is a security critical API design question, we should make sure that the behavior doesn't imply implicit side-effects, which are badly understood but cause risk of exposing sensitive user data accidentally.

[dchohfi]

@mrackwitz great points, the backgroundAccessRequired property seems to be helpful to detect issues before submitting to beta or AppStore.

[jpsim]

I just created #3223 and #3225 to address these points, as discussed with the cocoa team this morning in our weekly meeting.

[mrackwitz]

I think, we can close this in favor of the issues created by @jpsim.