[Feature Request] Add overlayfs deploy mode for Linux

[deadmeu]

It would be great if we could use overlayfs to deploy the mods rather than hard-linking, as this would allow using read-only game directories, preventing any contamination of the original game directory. Flatpak users could easily make use of this by only providing read-only access to those directories using Flatpak's permission system.

[limo-app]

This is a nice idea. Since i have never used OverlayFS, it will take some time to read up and implement.

[deadmeu]

I did some preliminary research on it and envision it would work like this (sorry about the brain dump):

1. Deployer is created, configured to use an "Overlay" mode (disabled on non-Linux systems and Linux systems that lack the capability. Maybe Windows/macOS could have some implementation in the future?).
2. When the game is launched through Limo (I haven't actually used Limo yet, and am assuming it works in this fashion where you click a button and the game is launched), the game's Steam directory (.../steamapps/common/[game_title]) and Limo's mods staging directory are mounted using overlayfs back to the Steam directory.
3. The game launches and plays as normal.
4. When the game is closed the overlay mount is unmounted.

Some thoughts and concerns:

• Everything has to be on the same filesystem.
• I'm not sure how it behaves inside a Flatpak environment.
• You need sudo privileges to run the mount command. Some super quick research shows that it might be possible to work around this issue using namespaces, but I haven't looked into it much. Perhaps the Flatpak environment could make this easier?
• Steam may try to update game files in the background when you launch the game, unless it is launched in offline mode.
• We can mount the target merged directory to the lowerdir Steam directory, this will work just fine.
• We could mount both directories as read-only: mount -t overlay overlay -o lowerdir=./steam-dir:./mods-staging ./steam-dir
  • Mounting them in this fashion causes the steam-dir contents to be read-only. If you try to edit the contents of the files (which at this point will contain the original contents of steam-dir as well as the contents of mods-staging), you get an error. This might work for some (perhaps even most) games, but if the game (or Steam) tries editing the contents, it might cause problems.
• We could instead mount the steam-dir as a lowerdir, and the mods-staging dir as an upperdir, and create a third work-dir directory to use as the workdir: sudo mount -t overlay overlay -o lowerdir=./steam-dir,upperdir=./mods-staging,workdir=./work-dir ./steam-dir
  • Mounting them in this fashion makes them appear editable. You can open any file in steam-dir and edit it. But these changes will only persist for files belonging to the upperdir (mods-staging), and not the lowerdir (steam-dir). Any modifications to files in the lowerdir causes them to be copied over to the upperdir, with the modified files persisting in that directory. The true version of steam-dir on disk will not have any changes persisted.
  • In this mode, if changes are made to the game files (e.g. Steam doing an update in the background) the changes either may not apply correctly during runtime (not sure how large files in steam-dir will behave to large changes), and at the very least will not persist when the steam-dir is unmounted. This could cause issues for users as Steam may try to download + apply the same updates / changes over and over again every time the user launches the game (because they will be lost when the game is closed and steam-dir gets unmounted.
  • Still probably don't want the mods-staging dir to be editable.
• I'm not sure how any of this will behave when trying to communicate with the Steam Flatpak. I'm not even really sure how Limo handles this currently. Maybe the overlayfs mount won't work properly between Flatpaks like this.
• If the directories are passed in as read-only to Limo, does that cause issues launching the games using the Steam Flatpak? Or maybe Steam's Flatpak's filesystem permissions take precedence in that case and should have write access? Not sure.
• When I create the overlayfs mount from my terminal, I get a new "Device" entry in Dolphin (KDE File Manager) showing the mount. This might be confusing or distracting to users. Maybe the Flatpak environment won't cause this at the host system level?

[limo-app]

Sorry for the late reply, i was ill lately.

2. When the game is launched through Limo (I haven't actually used Limo yet, and am assuming it works in this fashion where you click a button and the game is launched), the game's Steam directory (.../steamapps/common/[game_title]) and Limo's mods staging directory are mounted using overlayfs back to the Steam directory.

Launching a game currently does not affects mods at all. They are manually (un)deployed using separate buttons. I am not quite sure what the advantage of automatically undeploying all mods after the game exits would be.

• I'm not sure how it behaves inside a Flatpak environment.

In order to run games/ tools, Flatpak Limo needs permission to run arbitrary commands on the host, which would include mounting.

• You need sudo privileges to run the mount command. Some super quick research shows that it might be possible to work around this issue using namespaces, but I haven't looked into it much. Perhaps the Flatpak environment could make this easier?

The root privileges might be an issue. A user could add the required command to /etc/sudoers, eliminating the requirement for a password. But this seems like a bad idea, as it would be confusing for some users and also potentially a security risk. I will look into other ways around this.
As for Flatpak related issues: I believe there would be no difference in how this behaves, though i don't know all that much about the internals of how the sandbox is implemented. AFAIK, Flatpak uses bind mounts to allow access to additional directories. I don't know of any way to manually mount anything from inside the sandbox, other than running the mount command directly on the host.

• If the directories are passed in as read-only to Limo, does that cause issues launching the games using the Steam Flatpak? Or maybe Steam's Flatpak's filesystem permissions take precedence in that case and should have write access? Not sure.

I would have to test this but believe that this should not cause issues with Flatpak Steam.

Overall this seems doable and a useful addition. Though it may take time until i get around to implementing this as other features have a higher priority at the moment.

[Bereim]

• You need sudo privileges to run the mount command. Some super quick research shows that it might be possible to work around this issue using namespaces, but I haven't looked into it much. Perhaps the Flatpak environment could make this easier?

The root privileges might be an issue. A user could add the required command to /etc/sudoers, eliminating the requirement for a password. But this seems like a bad idea, as it would be confusing for some users and also potentially a security risk. I will look into other ways around this.

You can use fuse-overlayfs, it allows overlay filesystems to be made without root.