Hello there, I am aware that a similar question may have already been asked somewhere, but to be honest I still don’t fully understand the SailJail concept and sandboxing in Sailfish. Is SailJail only about permissions? or is it limiting apps further in some way? Also is sandboxing a completely different thing from SailJail, or they are more or less the same?
I’ve seen the explanations on Github and jolla blog, as well as a few posts on the forum, but to be honest I don’t know how is it different from let’s say android, when the apps also ask for permissions. I would be grateful if someone could explain it to me in a detailed manner.
Yes, here you can see the list of possible permissions: GitHub - sailfishos/sailjail-permissions. If permissions are not specifically defined, a default profile will be used.
Nope.
SailJail, based on Firejail, provides the sandboxing. One is the mean and one is the result.
I don’t know either, since I’ve never used Android and never been interested in it. I bet there are loads of info on that out there. Maybe you could start by reading the Sailfish documentation on SailJail and then read about Android and do a comparison.
I don’t know either, since I’ve never used Android and never been interested in it. I bet there are loads of info on that out there. Maybe you could start by reading the Sailfish documentation on SailJail and then read about Android and do a comparison.
Neither did I, recently swapped my Nokia n900 (after 11 years) to E6 and now I am on xperia x to check if Sailfish is for me. I will for some kind of documentation.
Yes, here you can see the list of possible permissions: GitHub - sailfishos/sailjail-permissions. If permissions are not specifically defined, a default profile will be used.
I’ve seen that, good read.
Nope.
So the whole sandboing is just restricting an app access to requested permissions?
Thank you for clarifying that for me. I thought that there was some another enigmatic layer of protection/separation of user data from apps, but now I understand how it works.
See Settings => select app to view the permissions for the selected app after installing the app.
Be aware that an app will get a lot permissions when sailjail is not defined due to “Our intention is that when we turn the sandboxing on for all apps, the current existing apps will not be broken. Therefore, we need a default profile, which will be used in case an app hasn’t defined an application profile of its own. The default profile will have broad enough permissions to allow any previously Harbour-allowed app to function.”
And finally, in the future you should be able to switch permissions on and off in the settings ui of the app. edited after remark of @vige
Please don’t mix these two separate things. Although what you wrote is almost correct, disabling sandboxing and default permissions are not the same.
The default permissions, which are given to apps which don’t have the permissions defined, are indeed quite wide. Like you wrote, wide enough to allow old Harbour-allowed apps to function. This kind of apps are still allowed in Harbour.
Switching the sandboxing off (by Sandboxing=Disabled) does exactly what it says in the tin: It disables sandboxing altogether. So it allows apps to do literally anything, including things that are not allowed with the default permissions. This kind of apps are not allowed in Harbour.
One really annoying thing about sailjail is that it only creates the ~/.local/share/<app-name> directory in the “legacy” mode, i.e. when there’s no [X-Sailjail] section in the .desktop file at all. That forces the apps which need that directory to be persistent, to not specify the [X-Sailjail] section and end up requiring the full set of legacy permissions rather than the ones which the app actually needs. Otherwise that directory gets created inside the sadbox, lives inside the sadbox and disappears when the app exits.
I periodically see complaints “why is you app requiring so many permissions” in the Jolla Store. Well, that’s why
The point is that the app should use the new (backwards, javaesque) named directory structure, and access to the legacy one is just provided to be able to migrate out of. While that is fine to dislike, i don’t quite see what would need the old directory.
If the application sets its OrganizationName etc then the QStandardPaths should already point to the new place. So fresh installs really has no business writing to the old dir.
It does make sense to consider the new structure for fresh new apps, of course. The new structure doesn’t make the app incompatible with older releases of SFOS, the new app doesn’t need the old directory, you’re right.
Just as the old app doesn’t need the new directory as long as the old one works.
