In MacOS Sierra 10.12, Apple introduces a feature(headache) called 'Gatekeeper Path Randomization'. The anti-malware feature launches a new application in a read-only sandbox, if the app is launched from its original folder/location or if it was not moved directly to the root of the Applications folder(no sub folder). The resulting Read-only sandbox prevents a .TOML file from ever being written.
Reproduction Steps:
1: Ensure that all existing versions of Demonsaw are removed from MacOS
2: Download the installer archive from the Demonsaw Website and un-archive it.
3: Drag/Move the entire 'demonsaw_osx_64' folder to the Applications folder
4: Launch the MacOS console utility located in /Applications/Utilities. We will use this to confirm sand-boxing of the app.
5: Enter 'Demonsaw' into the search field to filter events, see below.
6: Launch Demonsaw.
7: Note a console event similar to that listed below, indicating a single-session copy of demonsaw.app being temporarily created in a sandbox.
SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/77/1t_hk2xd1kn3vplds17ytmbm0000gn/T/AppTranslocation/5D6569C3-DA7F-4F81-BBDC-C3DCA84657DC/d/demonsaw.app
From what I can tell, a unique version of Demonsaw will be created for each launch attempt. Each copy of the app will persist given that there is also an error deleting it after quit.
Summary:
Given that Demonsaw comes archived within a folder containing other files that appear essential, most users will drag the entire directory to the Applications folder. Demonsaw.app being in the original sub-folder will trigger Path Randomization, preventing users from saving any settings to the .TOML.
When the app is launched from the root of the Application folder it is not launched in a sandbox and can write any file it needs as expected. The only other concern is that visible files related to Demonsaw now appear among the other apps such as -psn and .TOML files, this is not a common practice. Ideally the .TOML and other files should be stored elsewhere or at the least be made hidden, most importantly the .TOML.
To resolve this we should encourage users to drag only the Demonsaw.app from the un-archived folder or .dmg(more common) directly into the root of the Application folder. Below I have provided an example of how applications are commonly presented to users when being installed. This method may prevent users from triggering the sand-boxing by moving just the .app
In MacOS Sierra 10.12, Apple introduces a feature(headache) called 'Gatekeeper Path Randomization'. The anti-malware feature launches a new application in a read-only sandbox, if the app is launched from its original folder/location or if it was not moved directly to the root of the Applications folder(no sub folder). The resulting Read-only sandbox prevents a .TOML file from ever being written.
Reproduction Steps:
1: Ensure that all existing versions of Demonsaw are removed from MacOS
2: Download the installer archive from the Demonsaw Website and un-archive it.
3: Drag/Move the entire 'demonsaw_osx_64' folder to the Applications folder
4: Launch the MacOS console utility located in /Applications/Utilities. We will use this to confirm sand-boxing of the app.
5: Enter 'Demonsaw' into the search field to filter events, see below.
6: Launch Demonsaw.
7: Note a console event similar to that listed below, indicating a single-session copy of demonsaw.app being temporarily created in a sandbox.
SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/77/1t_hk2xd1kn3vplds17ytmbm0000gn/T/AppTranslocation/5D6569C3-DA7F-4F81-BBDC-C3DCA84657DC/d/demonsaw.appFrom what I can tell, a unique version of Demonsaw will be created for each launch attempt. Each copy of the app will persist given that there is also an error deleting it after quit.
Summary:
Given that Demonsaw comes archived within a folder containing other files that appear essential, most users will drag the entire directory to the Applications folder. Demonsaw.app being in the original sub-folder will trigger Path Randomization, preventing users from saving any settings to the .TOML.
When the app is launched from the root of the Application folder it is not launched in a sandbox and can write any file it needs as expected. The only other concern is that visible files related to Demonsaw now appear among the other apps such as -psn and .TOML files, this is not a common practice. Ideally the .TOML and other files should be stored elsewhere or at the least be made hidden, most importantly the .TOML.
To resolve this we should encourage users to drag only the Demonsaw.app from the un-archived folder or .dmg(more common) directly into the root of the Application folder. Below I have provided an example of how applications are commonly presented to users when being installed. This method may prevent users from triggering the sand-boxing by moving just the .app