This is the complete file “/usr/share/sandbox/ntpd.sb” Now reboot the system from the original disk and ntp can write statistic files.īeware the fact that after a system upgrade sandbox files are modified and changed to default. The first line is for directory /var/ntp/ the second for all files in /etc/ntp/ where I put the leap seconds file. Now it’s possible to change files in /usr/share/sandbox. Typically the internal disk is now already mounted. For example from a boot-able USB stick or the disk created by “Time Machine”. The solution is to boot from an external device.
And of course it’s not possible to change this file either as unprivileged user nor as “root”. For “ntpd” it is “/usr/share/sandbox/ntpd.sb”. Therefore ntpd cannot write to this directory or files. This is typically done in /etc/ntp.conf with the additional linesįilegen peerstats file peers type day link enableįilegen loopstats file loops type day link enableįilegen sysstats file sys type day link enableīut directory “/var/ntp/” isn’t defined in sandbox config. For example I tried to run “ntpd” daemon with a config to write statistic files. Each processes is running in a so called “sandbox”.īut this generates some issues too. Everything is denied except those activities which are explicitly allowed. In traditional UNIX systems almost everything is allowed except those things which are forbidden. I've tried to find a method which is used to set it, but for now, to no luck.Apple’s operating system macOS is running in a “rootless” version. It appears that the app is somehow returning a wrong path for where to save the restoration data. I finally managed to get the real error out of the console. Why and how is the app trying to access this folder all the time, and why is it violating sandbox policy, even when not inside a sandbox? When allowed to do so, the app is constantly writing files into the Autosave Information folder. I've also overridden - (NSURL *)autosavedContentsFileURL to point to the App Support folder, and the URL is served correctly. I am using +(BOOL)autosavesDrafts while +(BOOL)autosavesInPlace returns NO.
The app doesn't use macOS autosaving (save in place) stuff, but if I'm correct, this Autosave Information folder is used for recovering app sessions. Sandbox: App(33811) System Policy: deny(1) file-write-unlink /Users/user/Library/Autosave Information/xx. The following kernel error prints in Console over and over again: When running the notarized app, it's caught in Gatekeeper. The app is NOT sandboxed, and entitlements are set correctly: -sandbox I'm using ad hoc (outside App Store) distribution for my document-based app.
0 kommentar(er)
