[GH-ISSUE #2140] Allow --appimage to accept a path to the appimage file. #1452

Open
opened 2026-05-05 08:06:50 -06:00 by gitea-mirror · 1 comment
Owner

Originally created by @crass on GitHub (Oct 5, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2140

Currently there's an issue where its not possible to successfully jail processes that attempt to run appimage binaries. One trivial example is when there's a wrapper script that executes the appimage binary. A harder example to work around is when running an X11 appimage binary via openbox's --startup option.

I propose that firejail be modified to optionally accept a path to an appimage binary (perhaps multiple paths?). When firejail is given this path it does the normal setup for appimage binaries, but it does not execute the appimage's AppRun as it normally would. Instead it creates a symlink to AppRun at the given appimage path. Then it continues setting up and executing the givien program to be jails.

Ideally, this should allow the jailed program to spawn an appimage process transparently. The command might look something like this:

firejail --x11=xephyr --appimage=/path/to/firefox.appimage \
    openbox --startup /path/to/firefox.appimage --profile /path/to/profile

This seems overly verbose having to repeat the appimage path, but it allows for the case where the specified program to jail is configured/prompted to execute an appimage by some means other than the commandline.

Originally created by @crass on GitHub (Oct 5, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2140 Currently there's an issue where its not possible to successfully jail processes that attempt to run appimage binaries. One trivial example is when there's a wrapper script that executes the appimage binary. A harder example to work around is when running an X11 appimage binary via openbox's `--startup` option. I propose that firejail be modified to optionally accept a path to an appimage binary (perhaps multiple paths?). When firejail is given this path it does the normal setup for appimage binaries, but it does not execute the appimage's `AppRun` as it normally would. Instead it creates a symlink to `AppRun` at the given appimage path. Then it continues setting up and executing the givien program to be jails. Ideally, this should allow the jailed program to spawn an appimage process transparently. The command might look something like this: ``` firejail --x11=xephyr --appimage=/path/to/firefox.appimage \ openbox --startup /path/to/firefox.appimage --profile /path/to/profile ``` This seems overly verbose having to repeat the appimage path, but it allows for the case where the specified program to jail is configured/prompted to execute an appimage by some means other than the commandline.
gitea-mirror added the
enhancement
label 2026-05-05 08:06:50 -06:00
Author
Owner

@matu3ba commented on GitHub (Feb 27, 2020):

@crass Why would you not move the file to a predefined folder for your appimages and start it from there with firejail?
openbox seems very specific to me.

One could argue, if firecfg should setup /usr/bin to link to an appimage folder.
However this would need special handling and hence might not be worth the effort yet.

<!-- gh-comment-id:592056575 --> @matu3ba commented on GitHub (Feb 27, 2020): @crass Why would you not move the file to a predefined folder for your appimages and start it from there with firejail? openbox seems very specific to me. One could argue, if firecfg should setup /usr/bin to link to an appimage folder. However this would need special handling and hence might not be worth the effort yet.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1452
No description provided.