User Profile

The temporary directory can be found using the following:FileManager.default.temporaryDirectory.appendingPathComponent("com.apple.dyld")I can also confirm that, at least in my case, I needed to change posix permissions and perform the operations on the items in the directory like I mentioned in my original reply. If I didn't change the posix permissions, the file protection I specified wasn't actually persisted. As far as applying the change recursively, by the time my code to fix the issue was executed, the closure file had already been generated with the wrong protection. It's possible this is happening because I didn't do this first thing when my app started, but I didn't want to take a chance on it.It might be worth looking into just finding the closure file for the currently running image (so you don't have to recursively traverse the file system during startup), but the app I'm working on is written with Xamarin which makes it a little more difficult for me to find the image id. Theoretically though, you could use this information to change the protection of just the com.apple.dyld folder and the current closure file, so this would be significantly less invasive and more performant. There would likely be a smaller chance of breaking things, since you'd potentially modify less files in the future if Apple ever decided to store more files in that directory.

You don't need to change the value in the entitlements to fix this issue. My understanding is that the value in the entitlements file is only used for the initial configuration of your app's data container when your app is first installed, but after that, any new files or directories are given the protection of the containing directory (unless you manually specify a different protection level when creating the item). So even if you were to change the protection in your entitlements, users who installed your update wouldn't see the benefits unless they did a clean install. (In situations unrelated to this one, I've seen sources online mention mixed results when changing the protection level defined in the entitlements.)Instead of changing the protection in the entitlements, you should be able to change the protection level for just the tmp/com.apple.dyld folder, and then it should work from then on. This allows the remainder of your data to stay at complete protection, and only the temporary files generated by com.apple.dyld will have the complete until first authentication protection. In my research, I've found you may need to temporarily add POSIX write permissions to the folder before being able to change the file protection. I also recursively changed the protection of every item in the directory for my first attempt, but I'm thinking that may be unnecessary since the filenames include the UUID of the main executable, which will change every time you compile your app.