[GH-ISSUE #3785] Allowing calling specific apps outside the sandbox or with a different firejail profile

gitea-mirror commented

2026-05-05 09:03:54 -06:00

Owner

Originally created by @mYnDstrEAm on GitHub (Dec 2, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3785

Is it possible to allow an app to call other apps to run outside the sandbox? Alternatively, is it possible to allow app A running with firejail profile A to call app B to run with firejail profile B?

In specific: I'd like to call the app Lutris from a firejailed instance of Kodi (Kodi 19 in Debian 10 with the the Kodi-Lutris addon).
There currently is no firejail profile for Lutris but if there was or if I'd create a very permissive profile for it (e.g. allowing everything but blacklisting a few folders) then I'd like Kodi to call Lutris with that firejail profile instead of it running in the sandbox of Kodi.
Alternatively, maybe one could allow/trust the app in the firejail profile for Kodi so that this specific app can run outside the sandbox.

Is that currently possible? I think this would be a very useful feature.

Relates to:

#6462

Originally created by @mYnDstrEAm on GitHub (Dec 2, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3785 Is it possible to allow an app to call other apps to run outside the sandbox? Alternatively, is it possible to allow app A running with firejail profile A to call app B to run with firejail profile B? In specific: I'd like to call the app `Lutris` from a firejailed instance of `Kodi` ([Kodi](https://github.com/xbmc/xbmc) 19 [in Debian 10](https://github.com/basilgello/kodi-nightly-debian-repo) with the the [Kodi-Lutris addon](https://github.com/RobLoach/lutris-kodi-addon/)). There currently is no firejail profile for Lutris but if there was or if I'd create a very permissive profile for it (e.g. allowing everything but blacklisting a few folders) then I'd like Kodi to call Lutris with that firejail profile instead of it running in the sandbox of Kodi. Alternatively, maybe one could allow/trust the app in the firejail profile for Kodi so that this specific app can run outside the sandbox. Is that currently possible? I think this would be a very useful feature. Relates to: * #6462

gitea-mirror

2026-05-05 09:03:54 -06:00

closed this issue
added the
enhancement

sandbox-ipc
labels

gitea-mirror commented

2026-05-05 09:03:57 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 3, 2020):

There currently is no firejail profile for Lutris

https://github.com/netblue30/firejail/blob/master/etc/profile-a-l/lutris.profile

Is it possible to [execute commands] outside the sandbox?

It's possible but unsupported. Meaning you will find a to execute a command outsite of the sandbox for a lot of profiles (especial weak profile e.g. blacklisting, permissive dbus, ...).

Is that currently possible? I think this would be a very useful feature.

Transition between sandboxes is difficult for sanbox implementations based on linux-namespaces like firejail. LSMs like SELinux have a better concept to do so.

IMHO the best way ATM is to use systemd-run or flatpak-spawn. Either by change the lutris command (if supported) or by placing a simple wrapper script before the real lutris in $PATH.

$ flatpak-spawn --host lutris
or
$ systemd-run --user lutris

D-Bus rules (if required, for kodi it's not the case).

dbus-user.talk org.freedesktop.systemd1
dbus-user.talk org.freedesktop.Flatpak

@rusty-snake commented on GitHub (Dec 3, 2020): > There currently is no firejail profile for Lutris https://github.com/netblue30/firejail/blob/master/etc/profile-a-l/lutris.profile > Is it possible to [execute commands] outside the sandbox? It's possible but unsupported. Meaning you will find a to execute a command outsite of the sandbox for a lot of profiles (especial weak profile e.g. blacklisting, permissive dbus, ...). > Is that currently possible? I think this would be a very useful feature. Transition between sandboxes is difficult for sanbox implementations based on linux-namespaces like firejail. LSMs like SELinux have a better concept to do so. IMHO the best way ATM is to use `systemd-run` or `flatpak-spawn`. Either by change the lutris command (if supported) or by placing a simple wrapper script before the real lutris in $PATH. ``` $ flatpak-spawn --host lutris or $ systemd-run --user lutris ``` D-Bus rules (if required, for kodi it's not the case). ``` dbus-user.talk org.freedesktop.systemd1 dbus-user.talk org.freedesktop.Flatpak ```

gitea-mirror commented

2026-05-05 09:03:58 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Dec 3, 2020):

Thank you! Very happy to see that somebody recently created a profile for Lutris now!
However, when I try to run Lutris 0.5.8.1 with that profile I get:

Could not detect ldconfig on this system
Failed to create DBusScreenSaverInhibitor for name org.freedesktop.ScreenSaver, path /org/freedesktop/ScreenSaver, interface org.freedesktop.ScreenSaver: g-io-error-quark: Could not connect: Permission denied (14)
Traceback (most recent call last):
  File "/usr/games/lutris", line 54, in <module>
    from lutris.gui.application import Application  # pylint: disable=no-name-in-module
  File "/usr/lib/python3/dist-packages/lutris/gui/application.py", line 41, in <module>
    from lutris.gui.installerwindow import InstallerWindow
  File "/usr/lib/python3/dist-packages/lutris/gui/installerwindow.py", line 17, in <module>
    from lutris.installer import interpreter
  File "/usr/lib/python3/dist-packages/lutris/installer/interpreter.py", line 14, in <module>
    from lutris.installer.installer import LutrisInstaller
  File "/usr/lib/python3/dist-packages/lutris/installer/installer.py", line 17, in <module>
    from lutris.util.game_finder import find_linux_game_executable, find_windows_game_executable
  File "/usr/lib/python3/dist-packages/lutris/util/game_finder.py", line 8, in <module>
    import magic
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 361, in <module>
    add_compat(globals())
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 325, in add_compat
    from magic import compat
  File "/usr/lib/python3/dist-packages/magic/compat.py", line 61, in <module>
    _open = _libraries['magic'].magic_open
  File "/usr/lib/python3.7/ctypes/__init__.py", line 369, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 374, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/bin/python3: undefined symbol: magic_open

Parent is shutting down, bye...

Any idea how this could be solved?

Transition between sandboxes is difficult for sanbox implementations based on linux-namespaces like firejail.

Couldn't there be some firejail software running that could be requested by the sandbox and depending on the profile of the requesting application allow a specific application to be launched by the sandboxed app by taking the request with the requested app/command to run and then running that command on behalf of said app? (Related question here).

IMHO the best way ATM is to use systemd-run or flatpak-spawn. Either by change the lutris command (if supported) or by placing a simple wrapper script before the real lutris in $PATH.

Which one of those two to use (or in which of those in which cases)?
The Kodi-Lutris addon only allows specifying the path to the Lutris executable (currently that's /usr/games/lutris).

@mYnDstrEAm commented on GitHub (Dec 3, 2020): Thank you! Very happy to see that somebody recently created a profile for Lutris now! However, when I try to run Lutris 0.5.8.1 with that profile I get: ``` Could not detect ldconfig on this system Failed to create DBusScreenSaverInhibitor for name org.freedesktop.ScreenSaver, path /org/freedesktop/ScreenSaver, interface org.freedesktop.ScreenSaver: g-io-error-quark: Could not connect: Permission denied (14) Traceback (most recent call last): File "/usr/games/lutris", line 54, in <module> from lutris.gui.application import Application # pylint: disable=no-name-in-module File "/usr/lib/python3/dist-packages/lutris/gui/application.py", line 41, in <module> from lutris.gui.installerwindow import InstallerWindow File "/usr/lib/python3/dist-packages/lutris/gui/installerwindow.py", line 17, in <module> from lutris.installer import interpreter File "/usr/lib/python3/dist-packages/lutris/installer/interpreter.py", line 14, in <module> from lutris.installer.installer import LutrisInstaller File "/usr/lib/python3/dist-packages/lutris/installer/installer.py", line 17, in <module> from lutris.util.game_finder import find_linux_game_executable, find_windows_game_executable File "/usr/lib/python3/dist-packages/lutris/util/game_finder.py", line 8, in <module> import magic File "/usr/lib/python3/dist-packages/magic/__init__.py", line 361, in <module> add_compat(globals()) File "/usr/lib/python3/dist-packages/magic/__init__.py", line 325, in add_compat from magic import compat File "/usr/lib/python3/dist-packages/magic/compat.py", line 61, in <module> _open = _libraries['magic'].magic_open File "/usr/lib/python3.7/ctypes/__init__.py", line 369, in __getattr__ func = self.__getitem__(name) File "/usr/lib/python3.7/ctypes/__init__.py", line 374, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: /usr/bin/python3: undefined symbol: magic_open Parent is shutting down, bye... ``` Any idea how this could be solved? > Transition between sandboxes is difficult for sanbox implementations based on linux-namespaces like firejail. Couldn't there be some firejail software running that could be requested by the sandbox and depending on the profile of the requesting application allow a specific application to be launched by the sandboxed app by taking the request with the requested app/command to run and then running that command on behalf of said app? (Related question [here](https://security.stackexchange.com/questions/240321/is-there-a-way-to-specify-in-a-table-which-executables-via-locations-hashes)). > IMHO the best way ATM is to use systemd-run or flatpak-spawn. Either by change the lutris command (if supported) or by placing a simple wrapper script before the real lutris in $PATH. Which one of those two to use (or in which of those in which cases)? The Kodi-Lutris addon only allows specifying the path to the Lutris executable (currently that's `/usr/games/lutris`).

gitea-mirror commented

2026-05-05 09:04:00 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 3, 2020):

Any idea how this could be solved?

lutris.local:

dbus-user filter
dbus-user.talk org.freedesktop.ScreenSaver
ignore dbus-user none

If this doesn't help, use just ignore dbus-user none.

Which one of those two to use (or in which of those in which cases)?

IDK if there are an reason for one or the other.

The Kodi-Lutris addon only allows specifying the path to the Lutris executable (currently that's /usr/games/lutris).

ok. This is still easier than playing with $PATH. Change it so e.g. /usr/games/firejail_esacpe_lutris_wrapper and add a script there.

Couldn't there be some firejail software running that could be requested by the sandbox and depending on the profile of the requesting application allow a specific application to be launched by the sandboxed app by taking the request with the requested app/command to run and then running that command on behalf of said app? (Related question here).

or here 😁 .

It could be, but that's a lot. Actually the daemon would need to be triggerd by custom overrides (e.g. replace /usr/bin/vlc with a own binary) which forwards this start, because it must be transparent for the application.

@rusty-snake commented on GitHub (Dec 3, 2020): > Any idea how this could be solved? lutris.local: ``` dbus-user filter dbus-user.talk org.freedesktop.ScreenSaver ignore dbus-user none ``` If this doesn't help, use just `ignore dbus-user none`. > Which one of those two to use (or in which of those in which cases)? IDK if there are an reason for one or the other. > The Kodi-Lutris addon only allows specifying the path to the Lutris executable (currently that's /usr/games/lutris). ok. This is still easier than playing with $PATH. Change it so e.g. `/usr/games/firejail_esacpe_lutris_wrapper` and add a script there. >Couldn't there be some firejail software running that could be requested by the sandbox and depending on the profile of the requesting application allow a specific application to be launched by the sandboxed app by taking the request with the requested app/command to run and then running that command on behalf of said app? (Related question here). or [here](#3714) :grin: . It could be, but that's a lot. Actually the daemon would need to be triggerd by custom overrides (e.g. replace /usr/bin/vlc with a own binary) which forwards this start, because it must be transparent for the application.

gitea-mirror commented

2026-05-05 09:04:00 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Dec 3, 2020):

lutris.local

Still getting that same error.

Change it so e.g. /usr/games/firejail_esacpe_lutris_wrapper and add a script there.

I already tried that but I guess I got to get firejail lutris working first as I can't run python /usr/games/lutris ...or even just lutris without a custom path as I just noticed - issue is here.

Actually the daemon would need to be triggerd by custom overrides (e.g. replace /usr/bin/vlc with a own binary) which forwards this start, because it must be transparent for the application

You mean it needs to be transparent for the requesting application which app is launched? If it requests "VLC" with some parameters the daemon could for example have a table with verified hashsums to ensure that VLC is actually VLC.

@mYnDstrEAm commented on GitHub (Dec 3, 2020): > lutris.local Still getting that same error. > Change it so e.g. /usr/games/firejail_esacpe_lutris_wrapper and add a script there. I already tried that but I guess I got to get firejail lutris working first as I can't run `python /usr/games/lutris` ...or even just lutris without a custom path as I just noticed - issue is [here](https://github.com/RobLoach/lutris-kodi-addon/issues/46). > Actually the daemon would need to be triggerd by custom overrides (e.g. replace /usr/bin/vlc with a own binary) which forwards this start, because it must be transparent for the application You mean it needs to be transparent for the requesting application which app is launched? If it requests "VLC" with some parameters the daemon could for example have a table with verified hashsums to ensure that VLC is actually VLC.

gitea-mirror commented

2026-05-05 09:04:01 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 7, 2020):

The request must be transparent, meaning there is no differences to a normal start of this other app. If you want that vlc for example adds code to talk with a firejail-daemon. Forget it! This will never happen. Why should the devs add much code and work for that few users with firejail.

If it requests "VLC" with some parameters the daemon could for example have a table with verified hashsums to ensure that VLC is actually VLC.

You know that there is one hash per build per release?!

@rusty-snake commented on GitHub (Dec 7, 2020): The request must be transparent, meaning there is no differences to a normal start of this other app. If you want that vlc for example adds code to talk with a firejail-daemon. Forget it! This will never happen. Why should the devs add much code and work for that few users with firejail. > If it requests "VLC" with some parameters the daemon could for example have a table with verified hashsums to ensure that VLC is actually VLC. You know that there is one hash per build per release?!

gitea-mirror commented

2026-05-05 09:04:01 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Dec 7, 2020):

Thanks for the explanation, even though I'm still not entirely sure what you mean. I wasn't suggesting that other apps like VLC would add code for firejail-support. If I can run VLC with command vlc with my user-account then firejail-daemon also running under my user-account could also run VLC by running command vlc.
(For the hash I was referring to the software that is associated with command vlc on the local machine, but that was just trying to make sense of your comment I think it would only be relevant at a later point if at all.)

In the specific usecase described above:

firejail kodi would have a firejail profile that allows it to request running lutris outside its sandbox
when the user requests to make use of lutris from within kodi by opening the kodi-lutris addon, firejail would detect the call to lutris and transform it into/create a request for firejail-daemon
firejail-daemon would then run lutris outside the sandbox (with any parameters from the request)
(from within the firejail sandbox, in kodi, it would be as if it had run lutris itself)

@mYnDstrEAm commented on GitHub (Dec 7, 2020): Thanks for the explanation, even though I'm still not entirely sure what you mean. I wasn't suggesting that other apps like VLC would add code for firejail-support. If I can run VLC with command `vlc` with my user-account then firejail-daemon also running under my user-account could also run VLC by running command `vlc`. (For the hash I was referring to the software that is associated with command `vlc` on the local machine, but that was just trying to make sense of your comment I think it would only be relevant at a later point if at all.) In the specific usecase described above: * `firejail kodi` would have a firejail profile that allows it to request running lutris outside its sandbox * when the user requests to make use of lutris from within kodi by opening the kodi-lutris addon, firejail would detect the call to lutris and transform it into/create a request for firejail-daemon * firejail-daemon would then run lutris outside the sandbox (with any parameters from the request) * (from within the firejail sandbox, in kodi, it would be as if it had run lutris itself)

gitea-mirror commented

2026-05-05 09:04:02 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 7, 2020):

This would work. "firejail would detect the call to lutris" that's a bit tricky, best would be to place a own program under /usr/bin/lutris which then forawrds the call to the firejail-daemon.

@rusty-snake commented on GitHub (Dec 7, 2020): This would work. "firejail would detect the call to lutris" that's a bit tricky, best would be to place a own program under /usr/bin/lutris which then forawrds the call to the firejail-daemon.

gitea-mirror commented

2026-05-05 09:04:02 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 4, 2021):

Do we want to implement something like this, or should we close?

@rusty-snake commented on GitHub (Jan 4, 2021): Do we want to implement something like this, or should we close?

gitea-mirror commented

2026-05-05 09:04:02 -06:00

Author

Owner

@ghost commented on GitHub (Jan 4, 2021):

Do we want to implement something like this, or should we close?

My two cents. The systemd-run workaround is very nice and should offer users a potential way of scripting together a custom solution to whatever it is they are trying to achieve. If it is possible to code-in allowing app A running with firejail profile A to call app B to run with firejail profile B that would be awesome. IMO lots of users are still unaware of firejail's default 'inherit the running sandbox' principle. Personally I would stop there and not implement calling specific apps outside any sandboxing. For me that comes too close to 'security by obtrusion' or 'insecurity by design'. That's not what we want at all.

@ghost commented on GitHub (Jan 4, 2021): > Do we want to implement something like this, or should we close? My two cents. The `systemd-run` workaround is very nice and _should_ offer users a potential way of scripting together a custom solution to whatever it is they are trying to achieve. If it is _possible_ to code-in allowing app A running with firejail profile A to call app B to run with firejail profile B that would be awesome. IMO lots of users are still unaware of firejail's default 'inherit the running sandbox' principle. Personally I would stop there and `not` implement calling specific apps `outside` any sandboxing. For me that comes too close to 'security by obtrusion' or 'insecurity by design'. That's not what we want at all.

gitea-mirror commented

2026-05-05 09:04:03 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Jan 5, 2021):

Personally I would stop there and not implement calling specific apps outside any sandboxing. For me that comes too close to 'security by obtrusion' or 'insecurity by design'. That's not what we want at all.

That's a good point.
However, this could be implemented in a way that's not 'insecurity by design' which my suggestion could indeed become. There are probably many ways this could implemented for additional, rather than more unreliable security / sandboxing...or at least it needs more in-depth knowledge / thinking about how to implement it for that to be the case.

For example there could be a single root-protected file that specifies which firejail profiles can allow calling a) which apps/commands b) with which other firejail profiles it's basically the same security as before: one basically only has to ensure that those firejail profiles are good and remain unchanged (e.g. via users/permissions, IDS, testing the profile, etc) and that this protected file does not allow an app to run commands with other firejail profiles that it shouldn't. Default firejail would have deliver this file in a blank state so nothing would change except if this file is changed. This would make it easy for people to implement the rest and in a secure way so. Firejail could even display a prompt or at least message box if it detected a change to this file requiring root-user confirmation that this changed config should be applied.

@mYnDstrEAm commented on GitHub (Jan 5, 2021): > Personally I would stop there and not implement calling specific apps outside any sandboxing. For me that comes too close to 'security by obtrusion' or 'insecurity by design'. That's not what we want at all. That's a good point. However, this could be implemented in a way that's not 'insecurity by design' which my suggestion could indeed become. There are probably many ways this could implemented for _additional_, rather than more unreliable security / sandboxing...or at least it needs more in-depth knowledge / thinking about _how_ to implement it for that to be the case. For example there could be a single root-protected file that specifies which firejail profiles can allow calling a) which apps/commands b) with which other firejail profiles it's basically the same security as before: one basically only has to ensure that those firejail profiles are good and remain unchanged (e.g. via users/permissions, IDS, testing the profile, etc) and that this protected file does not allow an app to run commands with other firejail profiles that it shouldn't. Default firejail would have deliver this file in a blank state so nothing would change except if this file is changed. This would make it easy for people to implement the rest and in a secure way so. Firejail could even display a prompt or at least message box if it detected a change to this file requiring root-user confirmation that this changed config should be applied.

gitea-mirror commented

2026-05-05 09:04:03 -06:00

Author

Owner

@pkillnine commented on GitHub (Apr 4, 2021):

This is something I would like, so that I can call other executables inside their own sandbox started from outsid ethe current sandbox. E.g. I have it setup so each application gets it's own application data directory in ~/.appdate/- which is set as $HOME when it's run by firejail, if I were to run rtv and open a video link in mpv, the instance of mpv that is run would have as it's application data directory /.appdata/rtv-/.appdata/mpv-.

Simple call outs to other programs is possible with a simple daemon using a FIFO, which I tested and works fine, however another thing I want to do is to be able to pipe into a called application, so for example a program could call a program and open a pipe to it's standard input, which isn't possible with a simple daemon that calls the program.

I'm wondering if it's possible to have the daemon be able to reattach a pipe to the called application?

@pkillnine commented on GitHub (Apr 4, 2021): This is something I would like, so that I can call other executables inside their own sandbox started from outsid ethe current sandbox. E.g. I have it setup so each application gets it's own application data directory in ~/.appdate/<program>-<version> which is set as $HOME when it's run by firejail, if I were to run rtv and open a video link in mpv, the instance of mpv that is run would have as it's application data directory <real-home-directory>/.appdata/rtv-<version>/.appdata/mpv-<version>. Simple call outs to other programs is possible with a simple daemon using a FIFO, which I tested and works fine, however another thing I want to do is to be able to pipe into a called application, so for example a program could call a program and open a pipe to it's standard input, which isn't possible with a simple daemon that calls the program. I'm wondering if it's possible to have the daemon be able to reattach a pipe to the called application?

gitea-mirror commented

2026-05-05 09:04:04 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 4, 2021):

I'm wondering if it's possible to have the daemon be able to reattach a pipe to the called application?

Just try it: systemd-run --user --pipe --wait --quiet --service-type=exec cat <<<'Hello, World!'

@rusty-snake commented on GitHub (Apr 4, 2021): > I'm wondering if it's possible to have the daemon be able to reattach a pipe to the called application? Just try it: `systemd-run --user --pipe --wait --quiet --service-type=exec cat <<<'Hello, World!'`

gitea-mirror commented

2026-05-05 09:04:04 -06:00

Author

Owner

@pkillnine commented on GitHub (Apr 4, 2021):

@rusty-snake i don't run systemd, do you have any other example I could try? nice to know it's possible though

@pkillnine commented on GitHub (Apr 4, 2021): @rusty-snake i don't run systemd, do you have any other example I could try? nice to know it's possible though

gitea-mirror commented

2026-05-05 09:04:05 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 4, 2021):

flatpak-spawn seems to act similar.

And you can use ssh if there is no net none.

@rusty-snake commented on GitHub (Apr 4, 2021): `flatpak-spawn` seems to act similar. And you can use ssh if there is no `net none`.

gitea-mirror commented

2026-05-05 09:04:05 -06:00

Author

Owner

@pkillnine commented on GitHub (Apr 4, 2021):

Actually ssh was a solution I was looking into a while back, but i stopped because I didn't want to have to deal with handling keys and such, also I thought maybe it would be a security risk as if I give application sandboxes ssh access then they could just run ssh and do anything outside the sandbox, rather than call only other sandboxed applications.

Ectually I will use a specified SSH key, which will be restricted to running sandboxed applications. Is there a way of making no authentication be required if the user ssh's into the machine from their own account? I think actually you can restrict the applications that are allowed to be run, although it seems somewhat convoluted to set up having this restriction for when ssh'ing from own account to own account.

@pkillnine commented on GitHub (Apr 4, 2021): Actually ssh was a solution I was looking into a while back, but i stopped because I didn't want to have to deal with handling keys and such, also I thought maybe it would be a security risk as if I give application sandboxes ssh access then they could just run ssh and do anything outside the sandbox, rather than call only other sandboxed applications. Ectually I will use a specified SSH key, which will be restricted to running sandboxed applications. ~Is there a way of making no authentication be required if the user ssh's into the machine from their own account? I think actually you can restrict the applications that are allowed to be run, although it seems somewhat convoluted to set up having this restriction for when ssh'ing from own account to own account.~

gitea-mirror commented

2026-05-05 09:04:05 -06:00

Author

Owner

@FastAlien commented on GitHub (May 16, 2021):

@mYnDstrEAm Hi, I've solved the issue with Lutris profile and prepared a pull request: https://github.com/netblue30/firejail/pull/4283

@FastAlien commented on GitHub (May 16, 2021): @mYnDstrEAm Hi, I've solved the issue with Lutris profile and prepared a pull request: https://github.com/netblue30/firejail/pull/4283

gitea-mirror commented

2026-05-05 09:04:06 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Jul 22, 2021):

@RandomVoid @rusty-snake Thank you! However, it's a problem with the kodi.profile. I'm using the Lutris-Kodi addon in Kodi and it fails because of that profile and not the lutris.profile. Should one include lutris.profile in kodi.local? Especially if not could you please also update the kodi.profile (or add some info on how a kodi.local profile should look like to make it work which could go into the kodi.profile in commented-out and be turned into a click-enabable option users get prompted for at some trigger for the kodi firejail profile in the future).

@mYnDstrEAm commented on GitHub (Jul 22, 2021): @RandomVoid @rusty-snake Thank you! However, it's a problem with the kodi.profile. I'm using the Lutris-Kodi addon in Kodi and it fails because of that profile and not the lutris.profile. Should one include lutris.profile in kodi.local? Especially if not could you please also update the kodi.profile (or add some info on how a kodi.local profile should look like to make it work which could go into the kodi.profile in commented-out and be turned into a click-enabable option users get prompted for at some trigger for the kodi firejail profile in the future).

gitea-mirror commented

2026-05-05 09:04:06 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 24, 2021):

Should one include lutris.profile in kodi.local?

No

Especially if not could you please also update the kodi.profile

So

noblacklist /sbin
noblacklist /usr/sbin

makes it work?

@rusty-snake commented on GitHub (Jul 24, 2021): > Should one include lutris.profile in kodi.local? No > Especially if not could you please also update the kodi.profile So ``` noblacklist /sbin noblacklist /usr/sbin ``` makes it work?

gitea-mirror commented

2026-05-05 09:04:07 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Jul 24, 2021):

No, it doesn't...I get "Permission denied: '/home/username/.cache/lutris/lutris.log'". Obviously one could whitelist '/home/username/.cache/lutris/' which is what I tried with noblacklist in kodi.local. But that didn't work (same error).

@mYnDstrEAm commented on GitHub (Jul 24, 2021): No, it doesn't...I get "Permission denied: '/home/username/.cache/lutris/lutris.log'". Obviously one could whitelist '/home/username/.cache/lutris/' which is what I tried with noblacklist in kodi.local. But that didn't work (same error).

gitea-mirror commented

2026-05-05 09:04:07 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 24, 2021):

What did you tried? whitelist or noblacklist or ignore? And which path?

This is how it should look like I guess.

noblacklist ${HOME}/.cache/lutris

@rusty-snake commented on GitHub (Jul 24, 2021): What did you tried? `whitelist` or `noblacklist` or `ignore`? And which path? This is how it should look like I guess. ``` noblacklist ${HOME}/.cache/lutris ```

gitea-mirror commented

2026-05-05 09:04:07 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Jul 24, 2021):

Thank you, that was a stupid mistake: I wrote out the entire home path instead of using that variable. It finally works with this in kodi.local:

noblacklist /sbin
noblacklist /usr/sbin
noblacklist ${HOME}/.cache/lutris
noblacklist ${HOME}/.local/share/lutris
noblacklist ${HOME}/.config/lutris
noblacklist /usr/share/lutris/

It's really useful to have Gaming via Lutris added to Kodi so I think it would be good if this could added to kodi.profile, or an additional profile like kodi+lutris.profile.

I had to add a few things to kodi.local earlier to make Kodi work properly (ignore disable-mnt and noblacklisting some media source folders).

Maybe there could be a way to make it easier for users to configure profiles if needed modifications for specific use-cases are known (the lutris-kodi addon) or common (additional external media sources folders) like prompting the user about it or showing some console output that can make the needed changes by pressing some button.

@mYnDstrEAm commented on GitHub (Jul 24, 2021): Thank you, that was a stupid mistake: I wrote out the entire home path instead of using that variable. It finally works with this in kodi.local: ``` noblacklist /sbin noblacklist /usr/sbin noblacklist ${HOME}/.cache/lutris noblacklist ${HOME}/.local/share/lutris noblacklist ${HOME}/.config/lutris noblacklist /usr/share/lutris/ ``` It's really useful to have Gaming via Lutris added to Kodi so I think it would be good if this could added to kodi.profile, or an additional profile like kodi+lutris.profile. I had to add a few things to kodi.local earlier to make Kodi work properly (ignore disable-mnt and noblacklisting some media source folders). Maybe there could be a way to make it easier for users to configure profiles if needed modifications for specific use-cases are known (the lutris-kodi addon) or common (additional external media sources folders) like prompting the user about it or showing some console output that can make the needed changes by pressing some button.

Rows
Columns

[GH-ISSUE #3785] Allowing calling specific apps outside the sandbox or with a different firejail profile #2387