[Flatpak] Reduce filesystem permissions #413
Comments
jannuary
changed the title
jannuary
changed the title
|
With #436 - all filesystem permissions that are related to letting a user open an arbitrary file can be removed. As far as Bottles is concerned. Regarding Windows app that open/save files; I see 3 options
WDYT? |
Surely the second and third points are the best. What I don't understand is how it is possible that in my tests, even removing the permissions I am able to browse and pick files from the system using wine explorer. |
|
Maybe the sandbox is disabled by GNOME Builder or flatpak-builder? |
Exactly |
This explains A LOT of things. It is time for me to start using more Flatpak packages. |
|
Yes, it took me a while to understand the subtleties of flatpak when I started targeting it. It was quite frustrating. I think the developer experience could be better there. When I want to test/share the real deal, I build a bundle flatpak-builder --user --force-clean --repo=repo --install-deps-from=flathub flatpak com.usebottles.bottles.json
flatpak build-bundle repo Bottles.flatpak com.usebottles.bottles --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo
flatpak --user install Bottles.flatpakGNOME Builder also offers this IIRC EDIT:
https://docs.flatpak.org/en/latest/flatpak-builder-command-reference.html#idm1400 |
Thanks for the informations I understand their decision to add the |
|
We agree 😄 Also, it was unclear to me that Please do create an issue - I'll happily share my similar experience there as well https://github.com/flatpak/flatpak-builder/issues/new |
Great idea, I'll do it |
|
#130 is a requirement to consider dropping the following permissions note that Bottles will probably need a 'migrator' so even after #130 - these permissions might be always required @mirkobrombin what is |
Btw I just saw that |
|
Safely as in "app won't crash" or safely as in "won't break any feature"? What is a user wants to impot a prefix from |
Safely as: "won't break anything and it is not necessary to import prefixes from there"
That is the default path of the prefix created by wine. The user might want to bring it to Bottles but even though we offer this functionality, it is not officially supported and there are very few cases where a 'bottled' prefix works. |
What about https://github.com/bottlesdevs/Bottles#backward-compatibility-triumph ?
this is the importer right? If I had something to import it would automatically list it? Do you think it would make sense to let users choose a folder to import via portal instead? Perhaps as a fallback. If so, only "--filesystem=~/.local/share/bottles:ro" would be required for now. |
It has been a very long time and two major versions since I wrote about back compatibility. I think it could be the first step to retire v1 due the next coming major. At the moment it list automatically but it might be a good idea to allow the user to select the path using the portals. Also .local/share/bottles will be removed in the near future, as the Flatpak now store inside the .var/app/com.usebottles.bottles/data directory. |
|
Ok then for now I suggest we remove all permissions (and break the importer) and add to the flathub repo README.md how to use the importer with Flatseal. I will create a follow up ticket to change how the importer work. WDYT? |
I agree |
|
@mirkobrombin can you assign me ? |
|
|
The current situation isn't perfect but is temporary and will allow us to solve the problem once and for all. See #413 (comment) |
Thank you for your efforts and thank you for listening. |
|
Reducing filesystem permissions does not work well with programs that bundle their own DLLs (or other assets). Say I have |
|
If we give the flatpak that permission again, the issue (#572) should be closed. I don't think it is possible to give access to an entire folder through the GtkFileChooserNative because the user has to select the file and not the path. I believe that the lack of at least this permission is blocking the functioning of the main Bottles feature (starting windows executables), but I also think we shouldn't give in, to keep Bottles on the road to full-sandbox. @sonnyp what is your opinion on this? Do you think there is an easy way to solve or do you think it is better to explain better how to give the user the responsibility to add permissions to Bottles? As I thought Bottles, the target is the inexperienced user (despite everything), maybe a step by step tutorial should be done? Or maybe it is possible to integrate the permissions management in Bottles and act through flatpak-spawn in a controlled way? Regarding the last proposal, we could show a dialog box with the exposed paths and a simple + to expose others. Since we need to execute commands on the host, we could use flatpak-spawn (requires permissions in manifest) to give Bottles new permissions. So Bottles at the first start is full sandboxed and the user can (at his own risk) expose path in a simple way (even if I would point out the risk with a warning). |
|
Bottles shouldn't rely only on portals and |
I agree and on what you say I propose another solution: to introduce the user to the world of sandboxes. So, since the problem here is that the executable (with its dlls) are out of the sandbox, it would be possible to explain to the end user that these files must be moved inside the sandbox, perhaps taking advantage of the functionality of this issue: #572 So each bottle has its homedir (maybe sharable in the future) inside the bottle itself and the user place its executables in it, then the runner will have all the required permissions. |
|
From a user perspective, I don't think that will be good for the inexperienced user. The inexperienced user is more likely to give up and look for a different program instead of moving their files around. So, I can think of a few options that may work:
|
|
FYI there is a feature request to add an option to allow access to the whole directory wile opening a file flatpak/xdg-desktop-portal#463 |
This would be the perfect solution to the problem. I'll keep an eye on it, thanks! |
Wouldn't this negate the whole sandbox? I'm specifically currently trying to find out if bottles flatpak would provide a suitable sandbox to make origin usable, cause the Lutris Flatpak is still not mature, so i would vote against this approach ;) |
|
These are current perms Bottles/com.usebottles.bottles.dev.yml Lines 9 to 24 in 8af6ea3 |
|
@mirkobrombin Why |
There is an experimental feature in Bottles which aim to provide a per-bottle sandbox. It uses flatpak-spawn (with no --host) inside the flatpak and bwrap outside. |
|
oh ok thanks for the tip |
|
Related to this topic? #2990 |
|
#2999 (Flatpak portal problem with mounted SMB / CIFS share folder set as a Drive in Bottles) |
|
It's been a while since I used Bottles, but does this: Already have a notice exposed in the app? I know that there is a notice the first time you try to run an executable, but in my opinion, the message is still rather unclear and has jargons that can confuse new users. IMO drawing direct parallels to Android/iPhone folder limitation would probably feel more understandable to new users (especially those on Steam Deck) than the long notice Bottles have right now. Just say something like "By default, similar to many phone apps, Bottles is restricted to opening apps and files in /home//Documents/Bottles" or somewhere along that line would be clearer to most users not familiar with the terms and provides a non-hidden folder that they can just easily drop their games and apps into. I think that solution would be nice as, while flatpak/xdg-desktop-portal#463 will be great, there are apps with weird folder structures like Hitman 3, which have executable in a subfolder of the game's folder. I like the idea of just telling users to straight-up use ~/Documents/Bottles better. |
|
Why was this closed? About 2 weeks ago @mirkobrombin replied to me on another issue this:
|
https://docs.flatpak.org/en/latest/portals.html#portal-support-in-gtk:
|
(Moved from com.usebottles.bottles#120)
Currently, Bottles has a whopping 12 different filesystem permissions. Now that we use portals, it wouldn't hurt to go through different permission and reduce ones that aren't needed.
The text was updated successfully, but these errors were encountered: