macOS: Allow r/w access outside of default ini file location

[ToolTech]

Previously in pre 3.8.1 I could start multiple clients with different settings and the settings would be stored in separate config files. This way we could start multiple client for different devices and channels on a computer. (OS X)

In 3.8.1 this is mixed up. the names are lost and the settings are not stored. A Majord down step in functionality

[softins]

This is because the MacOS version in 3.8.1 is signed with a developer signature, and as a result, apparently has to run in a Sandbox. I believe this is a standard feature of signed apps, but @emlynmac could advise more, as he implemented the signing for us.

So now, the default ini file is stored in $HOME/Library/Containers/io.jamulus.Jamulus/Data/.config/Jamulus/Jamulus.ini. If you give a filename to -i, then it needs to be a relative filename, not one starting with /, ~ or $HOME. This will then be relative to $HOME/Library/Containers/io.jamulus.Jamulus/Data/, so you could say -i Config1.ini to store the config in .../Data directly, or -i .config/Jamulus/Config1.ini to store it alongside the default ini file.

This definitely needs documenting - apologies - but it was an unforseen side-effect of making the app signed in order to avoid the "Unknown developer" warning on installation.

[softins]

BTW, if you have your existing ini files, you can copy them to ~/Library/Containers/io.jamulus.Jamulus/Data/ or ~/Library/Containers/io.jamulus.Jamulus/Data/.config/Jamulus/ and the app should find them, if you give the appropriate -i parameter as mentioned above.

[ToolTech]

So you need to copy those files each time you install a new version then. Id rather use the old Security model then. Much cleaner to have external dir with configs Best regards! /Anders Modén

…

23 nov. 2021 kl. 15:59 skrev Tony Mountifield ***@***.***>:  BTW, if you have your existing ini files, you can copy them to ~/Library/Containers/io.jamulus.Jamulus/Data/ or ~/Library/Containers/io.jamulus.Jamulus/Data/.config/Jamulus/ and the app should find them. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[ToolTech]

And pretty strange to introduce this feature in a minor version ramp Best regards! /Anders Modén

…

23 nov. 2021 kl. 15:59 skrev Tony Mountifield ***@***.***>:  BTW, if you have your existing ini files, you can copy them to ~/Library/Containers/io.jamulus.Jamulus/Data/ or ~/Library/Containers/io.jamulus.Jamulus/Data/.config/Jamulus/ and the app should find them. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[softins]

So you need to copy those files each time you install a new version then.

No, only the first time. The name of the data directory won't change in future versions.

And pretty strange to introduce this feature in a minor version ramp

It was unexpected - well, it surprised me, at least.

[emlynmac]

As we started signing the macOS release, this also means we support app sandboxing on the signed release. This is a security feature of macOS apps more recently, to ensure that they only have access to their files and nothing else.

[softins]

As we started signing the macOS release, this also means we support app sandboxing on the signed release. This is a security feature of macOS apps more recently, to ensure that they only have access to their files and nothing else.

How would this apply to other kinds of app, such as MuseScore, for example, or a text editor, which can read and write arbitrary files?

[emlynmac]

As we started signing the macOS release, this also means we support app sandboxing on the signed release. This is a security feature of macOS apps more recently, to ensure that they only have access to their files and nothing else.

How would this apply to other kinds of app, such as MuseScore, for example, or a text editor, which can read and write arbitrary files?

Different apps can be set with different entitlements.
https://developer.apple.com/documentation/bundleresources/entitlements

[ann0see]

… so basically Jamulus would need to have a new entitlement to read/write files?

[gilgongo]

The config file location has been documented for the next website release.

@ann0see That would presumably mean the app would need to ask for permissions to write outside of its entitled space. I suppose that given the minority use of externally stored configs, such a warning would be OK. Better than the non-signed warning for all users at least.

[andresmattei]

Im having issues as well with the server app writing permissions. Since updating, it cannot write into local directory in order to save recordings

[emlynmac]

When we enabled App Store signing for the macOS app, we had to enable app sandboxing. This is a requirement for the Mac app store.
There are some restrictions here, which some users are finding around global file writing.

Some thoughts.

1. Does the un-signed release from the jamulus GitHub page work?
2. The sandboxed app has file writing permissions, just to a specific area of the filesystem and so do recordings get saved there or not?
3. We probably need to do a pass on the code to ensure that we write files only to the sandboxed area and document that.

Details of app sandboxing are here: https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6

[softins]

When we enabled App Store signing for the macOS app, we had to enable app sandboxing. This is a requirement for the Mac app store. There are some restrictions here, which some users are finding around global file writing.

How would these requirements differ for Jamulus, compared to an app such as MuseScore, which seems able to read and write files anywhere in the filesystem? The MuseScore app for Mac is signed, I believe, but I don't know whether it is available via the App Store, or just the MuseScore website.

Is it possible to sign apps just for installation, with no expectation of using the App Store, and therefore perhaps no need to sandbox? I don't think the App Store would give us much benefit.