为现有 sqlite 上的持久存储管理器更改 NSPersistentStoreFileProtectionKey答案

【问题标题】：Changing NSPersistentStoreFileProtectionKey for persistent store manager on existing sqlite为现有 sqlite 上的持久存储管理器更改 NSPersistentStoreFileProtectionKey
【发布时间】：2016-07-26 19:43:58
【问题描述】：

当应用程序在后台调用 addPersistentStoreWithType 时，我的 sqlite 文件有时不可用，我收到此错误：

[Model createPersistentStoreCoordinatorWithStoreURL:] line 387 $ sqlite 加密状态 NSFileProtectionCompleteUntilFirstUserAuthentication 错误：错误域=NSCocoaErrorDomain 代码=256“操作无法完成。（Cocoa 错误 256。）”UserInfo=0x1560e540 {NSUnderlyingException=授权被拒绝，NSSQLiteErrorDomain =23}

我发现这是因为文件仍然受到保护（默认为NSFileProtectionCompleteUntilFirstUserAuthentication，因此在用户重启后第一次解锁设备后，受保护的数据可用）。我觉得这行为不正确，因为我有大量的崩溃，我无法想象有很多人在野外重启后仍然锁定他们的设备。

因此，我现在正在添加我的持久存储协调器，并像这样调整配置

NSDictionary *options = @{
        NSMigratePersistentStoresAutomaticallyOption : @YES,
        NSInferMappingModelAutomaticallyOption : @YES,
        NSPersistentStoreFileProtectionKey : NSFileProtectionNone
    };

问题：

如果设备被锁定，这是否能确保文件在后台也可用？
如果我更改 NSPersistentStoreFileProtectionKey，这会破坏 sqlite（/内部数据）吗？
我没有在数据库中存储敏感数据，但是，您在使用NSFileProtectionNone 时是否发现安全问题？

【问题讨论】：

标签： ios objective-c core-data persistent-storage nspersistentstore

【解决方案1】：

是的，会的。这就是这把钥匙的作用。
不，不会。我有一个带有默认保护密钥的持久存储协调器，然后将 NSFileProtectionComplete 添加到它，并且数据正常。
是的。如果有人可以访问您的数据库文件，他可以轻松阅读它。查看这篇文章：https://github.com/project-imas/encrypted-core-data#strings-comparison

【讨论】：