Migrating configuration and data files for sandboxed apps

[Thaodan]

Can’t you copy over the old db to the new paths? The app should be able to access the old “harbour-foobar” directories when using the new sandbox profile.

[nephros]

@dcaliste

But you cannot create directories inside the jail that will be persistant. So, for all new users, their data are lost at each restart of the application.

I guess this matches up with the Firejail man page for a whitelist entry:

@man firejail

–whitelist=dirname_or_filename

Whitelist directory or file. A temporary file system is mounted on the top directory, and the whitelisted files are mount-binded inside. Modifications to whitelisted files are persistent, everything else is discarded when the sandbox is closed.

Now if you consider using a whitelist in your application profile, be aware that:

https://wiki.archlinux.org/title/Firejail"

Whitelists block everything what is not explicitly whitelisted. They should not be used in profiles for applications that need access to random locations (e.g., text editors, image viewers/editors).

[dcaliste]

Indeed, it has been designed for migration and it helps to copy data from the old directory to the new location. My remark was more about ‘was it possible, by not giving an organisation name, to get the old behaviour ?’ The answer is yes, but only for existing installations, which means ‘no’ in general for this specific question.

[direc85]

I was implementing migration of the storage folders of Whisperfish (Rust application), when I noticed that I could not simply move (i.e. std::fs::rename) the folders from the old to the new location if started with Sailjail (i.e. normally from the launcher icon). I had to copy-and-delete the files in them recursively instead. Luckily there’s a crate that provides fs_extra::dir::move_dir which does exactly that!

I believe this is because Sailjail mounts the old storage folders separately from the new ones, and as such they appear to be in different filesystems (mount points).

Hopefully this piece of information helps with others struggling with failing moves - although it looks like QDir::rename tries to move, and falls back to copy-and-remove automatically.

[thigg]

Can we have the information gathered in this thread put into the documentation/wiki?
At least I can’t find it there.

[vige]

It definitely should be there. The only reason it isn’t is that no one has added it there. I think this would be a perfect place: Application Permissions | Sailfish OS Documentation PRs are welcome

[thigg]

Is there now another recommended way for dealing with this in pure QML apps (like podqast) without disabling sandboxing alltogether?

[vige]

Unfortunately, no

[nephros]

@thigg

Is there now another recommended way for dealing with this in pure QML apps

Nemo.FileManager is not allowed in harbour, but its FileEngine provides methods to rename files, which should work to do similar things as the above methods do. Particularly:

        Method {
            name: "mkdir"
            type: "bool"
            Parameter { name: "path"; type: "string" }
            Parameter { name: "name"; type: "string" }
            Parameter { name: "nonprivileged"; type: "bool" }
        }
        Method {
            name: "rename"
            type: "bool"
            Parameter { name: "fullOldFileName"; type: "string" }
            Parameter { name: "newName"; type: "string" }
        }

To be harbour-compatible, I guess the only way is XMLHttpRequest, one with ‘GET’ to load a file to memory, and one with ‘PUT’ to save it to a new location.

Please be aware that the values of StandardPaths vary depending on when they are set, and LocalStorage location is not covered by them:

GitHub - nephros/sailjail_test