Feature Request: Support Flatpak sandbox

[mbugni]

Hi, I'm developing a Flatpak version of Doom Runner [1] for Linux systems. It's packaged along with GZDoom engine. It works, but requires some tricks for building and using:

• I applied a patch to DoomRunner.pro to put the executable in /app/bin folder
• engine and files must be selected from inside the sandbox, but browsing must be "forced" manually

Requirements

It would be nice if Doom Runner supports a runtime "sandbox mode", where:

• engines can be selected only from /app/bin folder
• files and configurations dialogs can pick up only from well known folders inside the sandbox, especially the ones specified by the following env variables [2]:

  $XDG_DATA_HOME      -->  ~/.var/app/io.github.Youda008.DoomRunner/data
  $XDG_CONFIG_HOME    -->  ~/.var/app/io.github.Youda008.DoomRunner/config

  Basically, the app should be able to browse only folders starting from well known internal sandbox roots. At build time, the binary outcome should be placed in /app/bin.

Advantages of Flatpak support

Works out of the box

Flatpak apps are easy to install and run.

Compatibility

Flatpak ensures that both runner and engines work on each Linux distro that supports it.

Isolation

The app folder ~/.var/app/io.github.Youda008.DoomRunner becomes a sort of "Doom backup" containing files and configurations (not executables). You can move it to another machine/distro and restore your configs and games for the Doom Runner app.

Links

[1] https://github.com/mbugni/DoomRunnerFlatpak [2] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Screenshot

[Youda008]

Oof. Sorry for stupid question, because i don't know how Flatpack works, but why is it required to select game files only from those predefined directories? For example i have all my mods and maps stored on a separate partition shared between Linux and Windows and making a copy of everything in ~/.var/app would be kinda wasteful. Also, wouldn't a separate build be a better idea than some runtime mode that can be turned on and off, since it requires a custom install directory?

[mbugni]

Sorry for stupid question, because i don't know how Flatpack works, but why is it required to select game files only from those predefined directories? For example i have all my mods and maps stored on a separate partition shared between Linux and Windows and making a copy of everything in ~/.var/app would be kinda wasteful.

Flatpak apps run in a restricted sandbox by design, but permissions can be extended [1]. I think we have to separate arguments:

Engines

To run an external command from the sandbox you have to:

• grant permission to app (option --talk-name=org.freedesktop.Flatpak)
• use the flatpak-spawn launcher [2] for running programs

Of course, Doom Runner could help to do this (by prefixing commands to run). Since engines must see the same "Doom Runner world", I think it's a good idea they come along the app.

Data and configs

Like for engines, permissions can be extended to allow access to files that reside outside the sandbox.

Also, wouldn't a separate build be a better idea than some runtime mode that can be turned on and off, since it requires a custom install directory?

Sure, this should the best approach. Take a look at [3] for customizing the build.

A good compromise would be to "suggest" (in file dialogs) a start point from Flatpak env variables (for engines, data and configs). People who want to respect the sandbox (one of the primary Flatpak goals) can just put files in suggested folders. Expert users can play with permissions to get different behaviours.

I know, it may sound different from the original goal of Doom Runner (a launcher for "every Doom stuff" in your PC). Personally, I like to have data and configs in a dedicated place, but it's a matter of taste.

Anyway, any suggestion is welcome.

If you want to do some experiment in a branch, I can adjust the app build. The final goal is to publish the app on Flathub [4].

Thanks

[1] https://docs.flatpak.org/en/latest/sandbox-permissions.html [2] https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-spawn [3] https://github.com/mbugni/DoomRunnerFlatpak/blob/main/io.github.Youda008.DoomRunner.yaml [4] https://flathub.org/

[mbugni]

Just some ideas for the sandbox.

Doom Runner could support some additional configurations for filtering/limiting paths and executables during browsing, like these:

executable_files=GZDoom
executable_paths=$PATH
config_paths=$XDG_CONFIG_HOME
data_paths=$XDG_DATA_HOME

These values could be available in an "Advanced settings" area of the "Initial setup" dialog. Empty values mean "no limitation", for example when Doom Runner is not executed in a sandbox. Default configurations could be injected at build time. Expert users could remove limitations, add permissions to the app, and/or customize these values, for example:

executable_files=zdoom.exe,lzdoom.exe
executable_paths=E:/Games/Doom
config_paths=E:/Games/Doom/configs
data_paths=E:/Games/Doom/iwads,E:/Games/Doom/maps,E:/Games/Doom/mods

[mbugni]

These values could be available in an "Advanced settings" area of the "Initial setup" dialog. Empty values mean "no limitation", for example when Doom Runner is not executed in a sandbox. Default configurations could be injected at build time.

Another approach is possible. I notice that Doom Runner use an options.json file for configs, in my case under the ~/.var/app/io.github.Youda008.DoomRunner/config/DoomRunner folder. A default config could be provided along with the app. A shell script can be used to launch Doom Runner: the script can provide an initial config by simply copying the default one to the correct place when it starts for the very first time. It's quite simple to get, and the default config can be provided by the app project as a simple json.

I provided an example in app project.

[Youda008]

Another stupid question: What's the problem with running DoomRunner outside of Flatpack sandbox environment and using it to start GZDoom inside its sandbox environment? You can normally start Flatpack version of GZDoom from shell, right? And DoomRunner is meant as a shell command generator. We can consider it a graphical version of bash limited to Doom only.

[mbugni]

First, let me show the actual result. As I mentioned, I provided a default config to the app. When it starts, I see this:

The "Initial setup" window doesn't appear, because a configuration is present. If I open it manually, I see this:

Now, what I have to do in order to play is:

• to copy/organize my WADs and PK3s under the data folder
• to choose my favorite combination
• to click "Launch!"

If I want to add another external engine, rather than the default one provided, I have to:

• give an extra-permission to the app (--talk-name=org.freedesktop.Flatpak)
• use the flatpak-spawn to launch the external engine

The flatpak-spawn command is something like sudo, it means: do something that you cannot do "normally". So, if you want to run the Flathub GZDoom, you have to launch:

flatpak-spawn flatpak run org.zdoom.GZDoom ...<any parameter>...

While, if you want to run a native engine, you have to launch:

flatpak-spawn /path/to/external/engine ...<any parameter>...

If you choose the Flathub GZDoom, you have to ensure that it can access to game files (because it's sandboxed).

It's not impossible, just a bit tedious. Anyway, you can do both.

[Youda008]

And what if i modify the logic of the launch command generation in the following way?

if engine executable is in "/var/lib/flatpak/app/"
    prepend the launch command with "flatpak run <app name (org.zdoom.GZDoom)>"
    if any of the additional files is outside of "~/.var/app/<app name>"
        add command line option "--filesystem=/dir/of/that/file"

I would rather avoid bundling DoomRunner with a Doom engine in a single Flatpak package, because someone would have to create such Flatpak package for every Doom engine people might want to use (DoomRunner with Zandronum, DoomRunner with ChocolateDoom, ...)

[Youda008]

What about this? https://github.com/Youda008/DoomRunner/pull/109/files#diff-e4692f6aa0975b01896e58d102bc0be6fce9a026e5ca3f0254a86e18b17311a8R119 https://github.com/Youda008/DoomRunner/pull/109/files#diff-4dfa3583df40c845e23e38db5448dee18c7118ecc2f475ef9685046c16307c22R3235

[mbugni]

What about this? https://github.com/Youda008/DoomRunner/pull/109/files#diff-e4692f6aa0975b01896e58d102bc0be6fce9a026e5ca3f0254a86e18b17311a8R119 https://github.com/Youda008/DoomRunner/pull/109/files#diff-4dfa3583df40c845e23e38db5448dee18c7118ecc2f475ef9685046c16307c22R3235

Just modified the Flatpak build to point the branch. It compile and run. Can you give an explanation of expected behaviour?

[mbugni]

And what if i modify the logic of the launch command generation in the following way?

if engine executable is in "/var/lib/flatpak/app/"
    prepend the launch command with "flatpak run <app name (org.zdoom.GZDoom)>"
    if any of the additional files is outside of "~/.var/app/<app name>"
        add command line option "--filesystem=/dir/of/that/file"

I would rather avoid bundling DoomRunner with a Doom engine in a single Flatpak package, because someone would have to create such Flatpak package for every Doom engine people might want to use (DoomRunner with Zandronum, DoomRunner with ChocolateDoom, ...)

I guess you are trying to understand which kind of engine and how to run it. I think we have two different problems with external engines:

1. run the engine
2. locate the engine

I cannot help with Snap because I don't know it: I assume it is similar to Flatpak.

1 - Run an external engine

The Doom Runner need an extra-permission --talk-name=org.freedesktop.Flatpak. It's a strong permission, but I think Flathub reviewers can accept it, since Doom Runner is a launcher. In any case, we need the flatpak-spawn command to launch an external engine. You can understand if you are in a Flatpak sandbox by looking for the /.flatpak-info file or the container variable:

[📦 io.github.Youda008.DoomRunner ~]$ env | grep container
container=flatpak

[📦 io.github.Youda008.DoomRunner ~]$ cat /.flatpak-info 
[Application]
name=io.github.Youda008.DoomRunner
runtime=runtime/org.kde.Platform/x86_64/5.15-22.08

[Instance]
instance-id=482039306
branch=master
arch=x86_64
flatpak-version=1.15.4

#######################
# A LOT OF OTHER INFO #
#######################

2 - Locate an external engine

There are two kind of engine:

• Native
• App (Flatpak or Snap)

2a - Locate a native engine

Browse the file system and choose an executable. Just as is.

2b - Locate an app engine

I think the safest way is to know the app identifier. For example, Flathub offers different engines:

net.dengine.Doomsday
io.github.fabiangreffrath.Doom
org.chocolate_doom.ChocolateDoom
org.zdoom.GZDoom

The user could input:

• The app type (Flatpak XOR Snap)
• The app identifier

Once the indentifier is know, the run command is simple:

flatpak run [OPTION...] [APP IDENTIFIER] ...

This approach is perfectly usable even if Doom Runner is used as a native executable and you want to run an app engine. This approach has no sense with other OS than Linux.

[Youda008]

Ok, i think i finally understand now.

What i did in MR https://github.com/Youda008/DoomRunner/pull/109 is a solution to issue https://github.com/Youda008/DoomRunner/issues/82. But what you really want is the DoomRunner itself to run inside Flatpak sandbox. In my opinion this does not make much sense: Why would you run an application in a sandbox, if you then grant it permissions to go outside of that sandbox and even execute external programs? But i guess there an advantage in it being available on all distributions, because DoomRunner doesn't have a package in standard distro repositories (only in AUR).

So i will do what you ask, but need to ask few more questions just to be sure.

1. So do i understand it right that for a) an app inside Flatpak env starting an app in the host env i have to use eg. flatpak-spawn /usr/games/gzdoom, b) an app inside Flatpak env starting an app in another separate Flatpak env i have to use eg. flatpak-spawn flatpak run org.zdoom.GZDoom. c) And what command do i need for an app inside Flatpak env starting an app inside the same Flatpak env?

2. How should i make sure that DoomRunner is started with the necessary permissions to be able to start apps outside of its env? Or will you somehow define it in your Flatpak package?

[mbugni]

But what you really want is the DoomRunner itself to run inside Flatpak sandbox.

Sorry, probably my initial request was not clear.

In my opinion this does not make much sense: Why would you run an application in a sandbox, if you then grant it permissions to go outside of that sandbox and even execute external programs? But i guess there an advantage in it being available on all distributions, because DoomRunner doesn't have a package in standard distro repositories (only in AUR).

For users: portable and easy to install. For developers: stable environment with well-known standards. For mantainers: focus on one version, avoiding to reinvent the wheel for each distro.

a) an app inside Flatpak env starting an app in the host env i have to use eg. flatpak-spawn /usr/games/gzdoom,

flatpak-spawn --host /usr/games/gzdoom

b) an app inside Flatpak env starting an app in another separate Flatpak env i have to use eg. flatpak-spawn flatpak run org.zdoom.GZDoom.

flatpak-spawn --host flatpak run org.zdoom.GZDoom

See:

$ man flatpak-spawn

c) And what command do i need for an app inside Flatpak env starting an app inside the same Flatpak env?

None. This is the reason I want to add a default engine along with Doom Runner. Both engine and launcher can run immediatly. If you take a look at my previous screenshots, you can notice that the default GZDoom engine on "Initial setup" is /app/bin/GZDoom. By combining engine and default config, you can get a "plug & play" app that requires just game files. This does not prevent to add other engines (a legacy one, a patched one or whatever).

2. How should i make sure that DoomRunner is started with the necessary permissions to be able to start apps outside of its env? Or will you somehow define it in your Flatpak package?

Can be defined in Flatpak manifest (the .yaml file) and it will be added at build time. I just modified the manifest to include the permission.

You can build and install the app yourself, by following the README.

You can jump into the app environment using the command:

$ flatpak run --command=bash io.github.Youda008.DoomRunner

You will get a shell prompt, then you can play with the sandbox, for example:

[📦 io.github.Youda008.DoomRunner ~]$ env | grep container
container=flatpak

[Youda008]

So i believe i have made what you asked for. I added a build option that will make the launcher behave as if it was being run from inside a Flatpak package. You can enable this options by adding CONFIG+=flatpak to the qmake command. Can you please try to build the latest state of branch https://github.com/Youda008/DoomRunner/tree/flatpak-snap-support and test if it does what you expect?

[Youda008]

Alright, seems like this task is now completed. 🎉 It's going to be released in 1.8.0 in 1-3 weeks. Thank you for making DoomRunner accessible for more Linux users, and thank you for having patience with me, i know it's hard 😁 I learned a lot from this. Looking forward for further cooperation. If any new problem comes up, either write it here, or create a new Issue. Have a nice summer.

[mbugni]

Thank you for making DoomRunner accessible for more Linux users, and thank you for having patience with me, i know it's hard grin I learned a lot from this. Looking forward for further cooperation.

Thank to you for developing open-source software. I'm just giving it another home.

I'll start the process for publishing Doom Runner on Flathub when release 1.8.0 will be available. It's ok to keep "Youda008" as author, or you prefer another name?

[Youda008]

Can you please briefly re-test if everything still work as expected? I had to rework some parts of code and there is a small chance that i broke something. I don't want to release a broken version which i will have to patch right away.

[mbugni]

I did a quick tour and it seems to work. Do you have in mind some areas that could not work?

[Youda008]

Automatic engine data paths deduction when adding a new engine, and launch command generation when Flatpak is used.

[Youda008]

Version with Flatpak support has been released.