Lutris needs access to the whole filesystem

[strycore]

Wihout having access to the whole filesystem, Lutris is inevitably run into issues. It won't detect games for the "Local" service. It won't be able to use secondary hard drives or SD cards, it won't be able to correctly handle saves for a bunch of native games.

The Retroarch Flatpak has filesystem permissions, so should Lutris.

[A6GibKm]

While I don't oppose to the idea in principle, I would prefer to exhaust the alternatives first.

We can certainly add home and /run/media today. Where would those native games store their data?

[strycore]

I don't see any viable alternative. I will send a PR

[kon14]

I honestly don't mean to rant just for the sake of it, but these permissions seem extremely loose for a game launcher.
The previous ones were already pretty bad.
Why did Lutris need access to my xdg folders in the first place?
Shouldn't such liberal fs access be something users opt-into instead of out-from?

If users wish for apps to access their secondary drives and mount points they can explicitly request it using an override.
If they're not into the cli they can ues Flatseal to conveniently configure that sort of stuff.

If it's due to Wine's default user folders these can be overriden on a prefix level or --persisted instead.
If it's for native games expecting to write anywhere they please, a HOME env var override could be specified so that these games write into a sandboxed directory.

Please reconsider this change.
Applications can be buggy and screw up big time even when they're not intentionally malicious.
Remember the time when Steam would just delete all of a user's files? Good times.

Apps should ideally have as little fs access as they possibly can ootb, even more so when they launch or are themselves proprietary.

[A6GibKm]

Normally I would agree, but you can't patch around what these legacy games try to do. I have found first hand that without home permissions some stuff wont work properly.

I hope it does not come to it, but if there is functionality that cannot work without filesystem=home, we will have to add it.

[kon14]

I hope it does not come to it, but if there is functionality that cannot work without filesystem=home, we will have to add it.

Home filesystem access was already added in #243, unless you're talking about post-beta state.

Frankly, I don't understand why Lutris needs any of these permissions.
All legacy games can be fooled into using a sandboxed directory as their $HOME by simply setting that env var, it can even be done on a manifest level so that everything running inside the Lutris sandbox and doesn't respect XDG's own env vars can use that directory instead.

There are more implications that need to be considered in a game launcher's case.
Heroic Flatpak for instance can't just undo its --filesystem=xdg-documents permission without breaking its users' saves as removing the permission would effectively result in it not being capable of automatically migrating the files (which is hard to do already as they're not well known) and so on.

Flatpak apps are not necessarily capable of accessing persistent user data created in an unavailable fs path from said their system package variants without user interaction. That's okay. Move to Flatpak, migrate once.
Undoing fs permissions down the line will break existing Flatpak installations.
Once you go down that rabbit hole, cleaning up the mess gets extremely harder to automate.

If an app like Heroic were to remove --filesystem=xdg-documents (used by default for Wine so as to persist save files) and replace it with --persist=Documents, reconfigure the default Wine paths or just set $HOME to something else (effectively fixing native games too), users that have previously used Heroic Flatpak will no longer be capable of accessing their existing Flatpak save files.

Flathub should be doubling down on existing apps needlessly requesting fs permissions, not adding even more of them.

[strycore]

Why did Lutris need access to my xdg folders in the first place?

My guess is that the initial Flatpak was based on the Wine flatpak and the original might have had them. Lutris doesn't need access to the XDG folders (but it needs access to a bunch of stuff outside those folders)

If they're not into the cli they can ues Flatseal to conveniently configure that sort of stuff.

Flatseal is not convenient. You have to 1) know it exists 2) know why you need to use it 3) know how to use it. Flatseal is a solution that is suitable for computer engineers, not the general public. We want to ship Lutris as a working product. Not something that is broken by default.

If it's due to Wine's default user folders

This is not due to Wine. Wine mostly work now. It's due to all the rest. But as long as people see Lutris as a Wine manager, it will never work out.

[kon14]

Flatseal is not convenient. You have to 1) know it exists 2) know why you need to use it 3) know how to use it. Flatseal is a solution that is suitable for computer engineers, not the general public. We want to ship Lutris as a working product. Not something that is broken by default.

Why ship it as a Flatpak at all if you're going to almost entirely bypass sandboxing?

A lot of users choose Flatpak primarily because of the added layer of security it provides, not the convenient cross-distro updates.

This is not due to Wine. Wine mostly work now. It's due to all the rest. But as long as people see Lutris as a Wine manager, it will never work out.

I am not suggesting that Lutris is merely a Wine manager. I simply fail to see why any of its runners depend on home folder access in order to function.

Which runners in particular? Which directories do they actually require? How do they use these directories? Can the runners not be made configurable? And if not, why wouldn't overriding $HOME work for them so that they can access any path they wish, only inside the sandbox instead?

I'm not simply writing any of this merely to condemn this change. I am legitimately puzzled as to why this is an issue for Lutris and interested in hearing about it.

Selecting roms from any arbitrary path for instance is not a requirement. Nor is picking files directly instead of using a file chooser portal.

[strycore]

Why ship it as a Flatpak at all if you're going to almost entirely bypass sandboxing?

Because it's the only option to ship Lutris on Steam Deck. I've never cared for sandboxing, especially for open source apps. This is not something I've ever asked for nor a feature that solves a problem I ever had.

I do understand the benefits of sandboxing the games that are executed from Lutris but that's a whole different project and it more related to Pressure vessel.

Most of the issues will arise from running native games, which can have all kinds of requirements and all have their way to storing configs and saves. Some respect the XDG standards, some don't.

But even for ROMs, it makes little sense to only be able to select a single file. mslug.zip can't run without neogeo.zip, a .bin cannot run without its .cue, Amiga games come in multiple ADF floppies, and on top of that require a BIOS file.

And I'm not asking for home access only, I'm asking for lutris to be able to see everything. Right now, Lutris doesn't see Steam and this breaks the Steam shortcuts feature. Rendering the whole project pretty much useless on Deck

[kon14]

Because it's the only option to ship Lutris on Steam Deck.

If Lutris can't or won't properly support Flatpak, why not stick to AppImage for SteamDeck users instead?

This is not something I've ever asked for nor a feature that solves a problem I ever had.

It is still a critical part of Flatpak and something a lot of users expect. Disabling sandboxing should be something users explicitly opt-into. Even IDEs can be made to work with it to a great extent, I can hardly believe Lutris can't due to technical limitations.

Most of the issues will arise from running native games, which can have all kinds of requirements and all have their way to storing configs and saves. Some respect the XDG standards, some don't.

Hence why I repetitively suggested overriding $HOME instead. Any path can be fooled into using a custom path for ~.
Seriously, try it out and see for yourself. export HOME=/tmp && ls ~/ should return the contents of /tmp instead of the ones relative to your actual home folder.

You can export it directly in the manifest using an env var override so that everything running inside the sandbox makes use of said path instead.
Might need to paired with --persist=some/path to create a persistent home relative path inside the sandbox.

Example override: sudo flatpak override --env=HOME=fake-home --persist=fake-home net.lutris.Lutris

But even for ROMs, it makes little sense to only be able to select a single file. mslug.zip can't run without neogeo.zip, a .bin cannot run without its .cue, Amiga games come in multiple ADF floppies, and on top of that require a BIOS file.

Why do these files need to be read from any single path there is? Why can't they at the very least stick to ~/Games or import the files once using a portal?

And I'm not asking for home access only, I'm asking for lutris to be able to see everything. Right now, Lutris doesn't see Steam and this breaks the Steam shortcuts feature. Rendering the whole project pretty much useless on Deck

Seeing Steam's files is not nearly as bad as having access to the entire home folder.
It's a valid use case. So stick with ~/.var/app/com.valvesoftware.Steam, ~/.local/share/Steam and ~/Games for that.

If users wish to add library folders or import files from any directory they can simply offer Lutris rw permissions to it.
There's no reason why everyone should get have to use an ootb insecure app because of it.

You can't technically see everything anyway as certain runtime restricted paths of the host fs just won't be exposed inside the sandbox no matter what permissions you request.

[strycore]

If Lutris can't or won't properly support Flatpak, why not stick to AppImage for SteamDeck users instead?

AppImages are not available from Discover, which is the main method of installing software on the Deck.

Hence why I repetitively suggested overriding $HOME instead.

That's planned, I seem to remember there was an issue open about it but I can't find it.

Right now, I don't even understand what the host permission is for since it won't allow Lutris to see the necessary files. This means:

• The "local" service is essentially broken as it won't ever see games installed on the system
• The custom executable feature of runners is broken since they won't be able to use stuff from /usr
• The Steam service is not active since Lutris can't see /usr/bin/steam (this may be worked around by pointing to the steam binary in the home folder)

Those 3 features are not the most essential for Lutris but now I have to account for their breakage in the client itself.

Since the host permission is useless, I don't see the point of keeping this issue open.