I’m making a Quick Web Apps, app for creating some sort of web apps. It need to read some paths, mainly system paths to find installed browsers, and other apps. For now, I’m doing this ugly thing: web-apps/src/common.rs at master · cosmic-utils/web-apps · GitHub
I think this approach is really bad. Does anyone have any better idea how to work with it? For not sandboxed environment, this mentioned crate (fde) works beautifully. It reads system paths and gives me results. For flatpak I need to append something and use not common paths. Maybe somehow we can (i don’t know ^^) redirect those sandboxed paths to normal paths, so fde crate will works as expected?
Unfortunately, this simply isn’t something that Flatpak is well-suited for.
One approach would be to create a statically linked (or dynamically linked with minimal dependencies) executable that you run on the host using flatpak-spawn --host. Your main app would still run inside the sandbox, but you’d communicate with this ‘agent’ process to interact with the host. This is what Ptyxis does to spawn shells on the host, for example.
Well, that sounds like a solution. So basically I need those 2 permissions, --talk-name=org.freedesktop.Flatpak
and --filesystem=host
and running my app with flatpak-spawn --host right? How to “automatic” this thing, so desktop file will have this setup? I want to make it as simple as possible for end user.
Just using flatpak-spawn to run the whole app outside of the sandbox is an terrible idea, if you ask me.
Its also not how Ptyxis works.
AFAIK Ptyxis works the following way:
The app itself is run normally inside the sandbox. However, it uses the Flatpak portal to launch a small process, which performs the task which need to be run on the host, outside of the sandbox. This is the agent.
The app and the agent communicate over dbus.
That way, Ptyxis can perform certain actions on the host without it running fully outside the sandbox.
To be honest, you current code, which appends the additional paths when running in Flatpak, is the best solution as of now, as your app stays in the sandbox.
If I recall correctly there was an proposal for an XDG desktop portal to request a list of desktop files, might want to keep an eye on that.
Finally: While this won’t solve your issue when running inside Flatpak, you should look into using paths relative to XDG_DATA_HOME and XDG_DATA_DIRS, otherwise there might be environments where the absolute paths could lead to wrong folders.
I require access to some folders to read, and some for writing browser profiles there. Any ideas if I can improve this somehow?
Ofc, you mentioned XDG_DATA_HOME so I will look into it.
Considering you need the system desktop files, for which no portal exists as of yet, you probably won’t get around those right now. But you should probably use :ro on host-os.
You may want to look if using the Dynamic Launcher Portal might be an option for you.
But if you need to keep these permissions, you should use xdg-data instead of ~/.local/share, as xdg-data maps to XDG_DATA_HOME.
These I don’t think are necessary. Especially on the first, you should read your app data from XDG_DATA_HOME/quick-webapps, which is on Flatpak provided under ~/.var/app.
And for the second I’m not sure where you would use this… The data folder for your own app is mounted automatically, so there’s no need to add that.
A note on XDG_DATA_HOME and the likes for config and cache: While the default, if they are not defined, is indeed ~/.local/share, these can be changes by the user (or sandbox systems like Flatpak), so you should always read the setting first. Your UI toolkit probably has a method that makes this check for you, or you could use the dirs crate.
You may want to look if using the Dynamic Launcher Portal might be an option for you.
Never heard of it yet I’m gonna learn something!
These I don’t think are necessary. Especially on the first, you should read your app data from XDG_DATA_HOME/quick-webapps, which is on Flatpak provided under ~/.var/app.
Yeah, but I want to keep also “native” version not sandboxed in works. So gonna consider this change. But wait, XDG_DATA_HOME will points to ~/.local/share if not sandboxed?
And for the second I’m not sure where you would use this… The data folder for your own app is mounted automatically, so there’s no need to add that.
Ok, so this what I’m doing here is kind of dirty ^^ Browsers require profiles to work. For example firefox. If we use flatpak firefox, it will need to adjust permissions to read profiles from outside. I just decided, I will write to ~/.var/app/org.mozilla.firefox/data/profiles/firefox path. So created web app wil works, firefox flatpak will see profiles because it will be in it’s own path with permissions and everyone will be happy ^^
Well, the Flatpak should always store its data in its sandboxed folder. If users have used that native version before, providing a guide on how to migrate the data should suffice.
If XDG_DATA_HOME is not set, ~/.local/share is considered the default location. But it is important to respect it if it is set. Like a mentioned before, look if your UI kit has methods to check for the location of the data directory or consider using the dirs crate.
That does make sense. However, you probably should narrow down the permission then to the folders of the browsers you actually supoort. So, ~/.var/app/org.mozilla.firefox for Firefox.
Well, the Flatpak should always store its data in its sandboxed folder. If users have used that native version before, providing a guide on how to migrate the data should suffice.
Ok, I will think how to solve this.
If XDG_DATA_HOME is not set, ~/.local/share is considered the default location. But it is important to respect it if it is set. Like a mentioned before, look if your UI kit has methods to check for the location of the data directory or consider using the dirs crate.
Yeah, I’m even using this crate as a helper for my needs. But maybe I will integrate it better.
That does make sense. However, you probably should narrow down the permission then to the folders of the browsers you actually supoort. So, ~/.var/app/org.mozilla.firefox for Firefox.
Well, current implementations is kind of optimal in that sense, even if browser change it’s app_id it will be updated in Quick Web Apps, so it will be still using proper path. Otherwise, I would like to change it and make new release each time and for each new supported browsers.
Let me ask. Do you think I should change this permission? For each browser separate or leave it as it is? I know by this I’m losing some trust so I don’t know…
So still I need host-os but at least :ro. Imho it looks better. The downside is… User will have to adjust browser permissions to read our folder with profiles (probably…) but I think they will be used to it since using flatpak and also Flatseal will help with this process a bit which I will document and make a short guide