[Automotive] Sandboxing for System Installed Application

[Juergen Ryannel]

Hi,

> On 25.08.2016, at 15:59, Martin Kampas <martin.kampas at jolla.com> wrote:
> 
> Hi Jürgen,
> 
>> This should be only be useful if you create a custom live enabled runtime which is installed on a device (for example a tablet) and is not allowed to write into its installed folder. In this case it need to find a writeable place for it’s data. Correct?
>> Or is it more the use case that there is a read-only workspace on a remote device and still we would like to update the user interface?
> 
> It applies also to the case when the standard QmlLive Runtime is used. I updated the documentation, explaining:
> 
> """Not all projects are designed so that they allow working on isolated panels or
> screens and it may be necessary to deploy whole project to a target device in
> order to execute it. Receiving updates normally requires write access to the
> deployed files. Depending on the target platform, the project may be deployed to
> a location which is not user writable. In most cases hacking on the file
> permissions after deployment can help, but a more convenient method is available
> - let the runtime store all updates in a writable workspace overlay. Use the \c
> -updates-as-overlay option to enable this feature.”""

Thanks for the update. This makes the use case more clear. I will need to update the qt documentation for this. Maybe you did already.

> 
>> So we could either lookup a temporary folder or ask QStandardPaths for a writeable location. In both cases the implementation makes a choice.
>> Personally I would like to see that there is a default strategy to find a writeable workspace location, which is not inside the implementation but can be set onto the livenode in case something is not writeable.
> 
> It uses QDir::tempPath() to find such a location. It can be influenced by setting a platform specific environment variable. The following change set further extends this to also use application and company name in order to get app specific path, much like it is done by QSettings (this needs to be a bit tuned for the case with the standard runtime).
> 
> I considered to allow overriding the location with a dedicated environment variable but I abandoned this idea as too dangerous - the location is subject to "rm -rf" and I do not want to imagine someone misunderstanding and setting it to $HOME or $PROJECTS or whatever valuable location :)
> 
> Every project may have its specific constraints - I would rather let the user control the mechanism used.
> 
> This also serves as a preparation step for adding support to receive updates for compiled-in resources (qrc).
> 
> I am thinking maybe the overlay should be persistent by default?

Lets see. 
If you use a writeable location. Surely the changes are persistent. If you use a read only location then the changes would be currently not persistent and purged on remote runtime exit. 
From the user perspective when he looks at the QML code of the remote workspace he would see in the read-only case his original source code and would not understand why the code behaves differently. Sure this is the opposite in the writeable workspace use case. 

After restarting the remote runtime in the read-only workspace use case the user would need to press publish all to sync its workspace again.

So it might be just the question to automate this syncing. Either by announcing to the bench: The remote workspace is a read-only workspace, on re-connection please publish all automatically or the remove runtime request the sync automatically on startup and maybe this behavior could be omitted.
The other option would be to announce only to the bench that the workspace is read-only and we can add an action to auto-sync on connection to the target. Most flexibility but adds an option, I would prefer a good default behavior.

So it seems I’m not in favor of persistent temporary data. And more in finding a transparent good default behavior for applying a sync on re-connect.


/ jryannel

> BR,
> Martin