setAttributes:ofItemAtPath:error: 应用 NSFileProtectionComplete 时可能失败的原因？
我开始将 iOS 4 数据保护应用于我的应用程序使用的文件。我担心 setAttributes:ofItemAtPath:error: 无法应用更改的可能性：是否存在一组离散的已知原因导致此方法失败？如果无法设置该属性，我没有良好的后备行为，因为出于商业原因需要设置该属性，因此我想知道是否应该担心调用失败。
I'm starting to apply the iOS 4 Data Protection to the files my app uses. I'm concerned about the possibility of setAttributes:ofItemAtPath:error: failing to apply the changes: is there a discrete set of known reasons why this method fails? I don't have a good fallback behavior in case the attribute cannot be set since it needs to be set for commercial reasons, so I'd like to know if I should worry about the call failing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我从未听说过它确实失败的情况，而且我能想到的大多数情况对于一般设备来说都是灾难性的（它们涉及加密硬件脱机，此时根文件系统无法再运行）用过的）。如果转换文件的行为需要额外的磁盘空间或内存，那么我认为它可能会因为缺乏这些原因而失败：但是我认为这一切都是由专用加密硬件就地和带外完成的，所以我对此表示怀疑需要这些东西中的任何一个。
您的后备策略应取决于您的风险分析。绘制非常的笔触，哪个更重要：您尝试存储在文件中的数据的机密性或可用性？如果它是机密性的，那么如果您无法保护该文件，您应该放弃尝试保存它。如果可用，您无论如何都应该保存内容。您所做的任何其他事情（报告或审核任何故障；陷入自提供的加密技术等）也需要适合您的威胁模型。
请记住，如果数据的机密性非常重要，需要对其进行加密，那么您应该在写入数据之前创建受保护的文件。如果您获取明文文件并将其转换为受保护的文件，则攻击者检索明文的机会仍然有限。如果这对您来说是一次重要的攻击，您应该尽力避免它。
I've never heard of a situation in which it does fail, and most of the ones I can think of would be catastrophic for the device in general (they involve the encryption hardware being offline, at which point the root filesystem can no longer be used). If the act of converting a file requires additional disk space or memory, then I suppose it could fail for lack of those reasons: however I think it's all done in-place and out-of-band by the dedicated encryption hardware so I doubt it needs either of these things.
Your fallback strategy should depend on your risk analysis. Painting very broad brush strokes, which is more important: confidentiality or availability of the data you're trying to store in the file? If it's confidentiality, then if you can't protect the file you should give up trying to save it. If it's availability, you should save the content anyway. Anything else you do (reporting or auditing any failures; falling through to a self-supplied encryption technique etc.) also needs to fit with your threat model.
Remember, if confidentiality of your data is important enough to encrypt it, you should create the protected file before you write into it. If you take a plaintext file and convert it into a protected file, there's a finite chance of an attacker retrieving the plaintext still. If that's an important attack to you, you should be trying to avoid it.