[GH-ISSUE #3249] settings in default.profile and disable-common.inc that break AppImages

gitea-mirror commented

2026-05-05 08:42:41 -06:00

Owner

Originally created by @bdantas on GitHub (Feb 26, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3249

I tested two completely different AppImages (Firefox.AppImage, which I downloaded from appimagehub.com, and Xscreensaver.AppImage, which I created from scratch myself) on Tiny Core Linux 64-bit with firejail 0.9.62.

The only way to get these two AppImages to run with firejail is to comment-out the following lines in default.profile:

caps.drop all
nonewprivs
noroot
protocol unix,inet,inet6
seccomp

and also comment-out these lines in disable-common.inc:

blacklist ${PATH}/fusermount
blacklist ${PATH}/nc

I discovered the above after much trial and error.

Perhaps firejail could learn to detect AppImages and use a different profile (e.g., default-appimage.profile) and include file (e.g., disable-common-appimage.inc) that do not contain the offending lines above?

@probonopd might also be interested in this information.

Originally created by @bdantas on GitHub (Feb 26, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3249 I tested two completely different AppImages (Firefox.AppImage, which I downloaded from appimagehub.com, and Xscreensaver.AppImage, which I created from scratch myself) on Tiny Core Linux 64-bit with firejail 0.9.62. The only way to get these two AppImages to run with firejail is to comment-out the following lines in **default.profile**: ``` caps.drop all nonewprivs noroot protocol unix,inet,inet6 seccomp ``` and also comment-out these lines in **disable-common.inc**: ``` blacklist ${PATH}/fusermount blacklist ${PATH}/nc ``` I discovered the above after much trial and error. Perhaps firejail could learn to detect AppImages and use a different profile (e.g., default-appimage.profile) and include file (e.g., disable-common-appimage.inc) that do not contain the offending lines above? @probonopd might also be interested in this information.

gitea-mirror

2026-05-05 08:42:41 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 08:42:44 -06:00

Author

Owner

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

Keep in mind that disabling almost all options makes using firejail at all questionable.

@Vincent43 commented on GitHub (Feb 27, 2020): Keep in mind that disabling almost all options makes using firejail at all questionable.

gitea-mirror commented

2026-05-05 08:42:44 -06:00

Author

Owner

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

That's a good point. Maybe the AppImage runtime could be tweaked to need fewer privileges? Alas, I'm just a user and don't know if that would be doable without crippling functionality.

@bdantas commented on GitHub (Feb 27, 2020): That's a good point. Maybe the AppImage runtime could be tweaked to need fewer privileges? Alas, I'm just a user and don't know if that would be doable without crippling functionality.

gitea-mirror commented

2026-05-05 08:42:46 -06:00

Author

Owner

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

it's not really about appimage runtime but about apps. Having one sandbox fits all results in almost no sandbox because one app needs this, other app needs that and so on. To overcome this we need to differentiate sandbox depending on called app but I don't know how feasible is this with appimages.

@Vincent43 commented on GitHub (Feb 27, 2020): it's not really about appimage runtime but about apps. Having one sandbox fits all results in almost no sandbox because one app needs this, other app needs that and so on. To overcome this we need to differentiate sandbox depending on called app but I don't know how feasible is this with appimages.

gitea-mirror commented

2026-05-05 08:42:46 -06:00

Author

Owner

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

I understand what you're saying, but that's not what I was suggesting. I was suggesting a generic profile that allows what all AppImages need in order to mount the squashfs payload via fuse--let's call it the generic "AppImage loading" phase (all AppImages need to be allowed to call fusermount, for example).

After that, sure--we are in app-specific territory where we can't predict what privileges are needed. That's a separate problem that perhaps could be solved by documentation in appimagehub that lets users of a specific AppImage know what additional (if any) application-specific privileges are needed beyond what's in the generic AppImage profile.

@bdantas commented on GitHub (Feb 27, 2020): I understand what you're saying, but that's not what I was suggesting. I was suggesting a generic profile that allows what _all_ AppImages need in order to mount the squashfs payload via fuse--let's call it the generic "AppImage loading" phase (all AppImages need to be allowed to call fusermount, for example). After that, sure--we are in app-specific territory where we can't predict what privileges are needed. That's a separate problem that perhaps could be solved by documentation in appimagehub that lets users of a specific AppImage know what additional (if any) application-specific privileges are needed beyond what's in the generic AppImage profile.

gitea-mirror commented

2026-05-05 08:42:47 -06:00

Author

Owner

@ghost commented on GitHub (Feb 28, 2020):

@bdantas I just saw https://github.com/netblue30/firejail/issues/2690 again and that reminded me that we have support for using a special ?HASAPPIMAGE: conditional in profiles (0.9.62 and later). Perhaps you can try this instead of commenting in disable-common.inc (so the default profiles are kept fully intact for non-appimage usage):

blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/nc
?HAS_APPIMAGE: noblacklist ${PATH}/nc

See https://github.com/netblue30/firejail/issues/2690#issuecomment-592274833.

@ghost commented on GitHub (Feb 28, 2020): @bdantas I just saw https://github.com/netblue30/firejail/issues/2690 again and that reminded me that we have support for using a special `?HASAPPIMAGE:` conditional in profiles (0.9.62 and later). Perhaps you can try this instead of commenting in disable-common.inc (so the default profiles are kept fully intact for non-appimage usage): blacklist ${PATH}/fusermount ?HAS_APPIMAGE: noblacklist ${PATH}/fusermount blacklist ${PATH}/nc ?HAS_APPIMAGE: noblacklist ${PATH}/nc See https://github.com/netblue30/firejail/issues/2690#issuecomment-592274833.

gitea-mirror commented

2026-05-05 08:42:47 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

Ok, so I created a barebones AppImage for testing. It does nothing but run this script:

#!/bin/sh
echo hello

The AppImage was created using the latest stable release (version 12) of AppRun-x86_64 and appimagetool-x86_64.AppImage available here: https://github.com/AppImage/AppImageKit/releases

Here is the AppImage if you'd like to inspect it: http://files.dantas.airpost.net/public/Dummy-x86_64.AppImage

The installed firejail is version 0.9.62 which seems to include AppImage support:

$ firejail --version
Error: cannot read UID_MIN and/or GID_MIN from /etc/login.defs, using 1000 by default
firejail version 0.9.62

Compile time support:
	- AppArmor support is disabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

I'm running the AppImage in a minimalistic 64-bit Tiny Core Linux machine (linux kernel 5.4.3) with this command in a terminal emulator:

$ firejail ./Dummy-x86_64.AppImage

As was the case with the two AppImages in my original post, Dummy-x86_64.AppImage is only able to echo hello in the terminal if I comment-out these lines in default.profile like this:

#caps.drop all
#nonewprivs
#noroot
#protocol unix,inet,inet6
#seccomp

and also comment-out these lines in disable-common.inc:

#blacklist ${PATH}/fusermount
#blacklist ${PATH}/nc

If I remove the pound sign from any of the lines above, the test AppImage fails to run.

If I have this in disable-common.inc:

blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/nc
?HAS_APPIMAGE: noblacklist ${PATH}/nc

Then the test AppImage also fails to run.

Conclusions:

It seems strange that so much needs to be commented-out in default.profile in order for even a barebones AppImage to run, but that's what I'm finding. It would be nice if someone could reproduce this.
The ?HAS_APPIMAGE trick has no effect in my test.

@bdantas commented on GitHub (Feb 28, 2020): Ok, so I created a barebones AppImage for testing. It does nothing but run this script: ``` #!/bin/sh echo hello ``` The AppImage was created using the latest stable release (version 12) of AppRun-x86_64 and appimagetool-x86_64.AppImage available here: https://github.com/AppImage/AppImageKit/releases Here is the AppImage if you'd like to inspect it: http://files.dantas.airpost.net/public/Dummy-x86_64.AppImage The installed firejail is version 0.9.62 which seems to include AppImage support: ``` $ firejail --version Error: cannot read UID_MIN and/or GID_MIN from /etc/login.defs, using 1000 by default firejail version 0.9.62 Compile time support: - AppArmor support is disabled - AppImage support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - firetunnel support is enabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled ``` I'm running the AppImage in a minimalistic 64-bit Tiny Core Linux machine (linux kernel 5.4.3) with this command in a terminal emulator: ``` $ firejail ./Dummy-x86_64.AppImage ``` As was the case with the two AppImages in my original post, Dummy-x86_64.AppImage is only able to echo _hello_ in the terminal if I comment-out these lines in default.profile like this: ``` #caps.drop all #nonewprivs #noroot #protocol unix,inet,inet6 #seccomp ``` and also comment-out these lines in disable-common.inc: ``` #blacklist ${PATH}/fusermount #blacklist ${PATH}/nc ``` If I remove the pound sign from **any** of the lines above, the test AppImage fails to run. If I have this in disable-common.inc: ``` blacklist ${PATH}/fusermount ?HAS_APPIMAGE: noblacklist ${PATH}/fusermount blacklist ${PATH}/nc ?HAS_APPIMAGE: noblacklist ${PATH}/nc ``` Then the test AppImage also fails to run. Conclusions: 1. It seems strange that so much needs to be commented-out in default.profile in order for even a barebones AppImage to run, but that's what I'm finding. It would be nice if someone could reproduce this. 2. The ?HAS_APPIMAGE trick has no effect in my test.

gitea-mirror commented

2026-05-05 08:42:49 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

P.S. I just tested the same Dummy-x86_64.AppImage in a totally different environment (Devuan ASCII with firejail version 0.9.44.8). Results were almost identical to the above. The only differences where these two:

In Devuan it's okay to leave nc blacklisted
The older firejail version complains that the ?HAS_APPIMAGE line is invalid

@bdantas commented on GitHub (Feb 28, 2020): P.S. I just tested the same Dummy-x86_64.AppImage in a totally different environment (Devuan ASCII with firejail version 0.9.44.8). Results were almost identical to the above. The only differences where these two: 1. In Devuan it's okay to leave _nc_ blacklisted 2. The older firejail version complains that the _?HAS_APPIMAGE_ line is invalid

gitea-mirror commented

2026-05-05 08:42:49 -06:00

Author

Owner

@ghost commented on GitHub (Feb 28, 2020):

@bdantas Thank you for doing extensive testing. I've made similar tests using your Dummy-x86_64.AppImage referenced above and can confirm (most of) your observations.

If I have this in disable-common.inc:

blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/nc
?HAS_APPIMAGE: noblacklist ${PATH}/nc

Then the test AppImage also fails to run.

As per man firejail the conditional '?HAS_APPIMAGE:' only works when it encounters '--appimage' as argument to the firejail command. At least as far as I can see in your responses throughout this issue that argument hasn't been used, which would explain it not doing anything positive in this context. In fact, using the '--appimage' on CLI (or it's counterpart 'appimage' in a profile file) is the recommended use of firejail with AppImages.

That being said, I can reproduce, so marking this as a bug. Strangely enough firejail --noprofile works (without making any changes to the default profiles) while firejail --noprofile --appimage does not. To me that suggests something is broken in the implementation of that parameter (in 1ad2d54c01/src/firejail/sandbox.c).

@ghost commented on GitHub (Feb 28, 2020): @bdantas Thank you for doing extensive testing. I've made similar tests using your Dummy-x86_64.AppImage referenced above and can confirm (most of) your observations. > If I have this in disable-common.inc: > > blacklist ${PATH}/fusermount > ?HAS_APPIMAGE: noblacklist ${PATH}/fusermount > blacklist ${PATH}/nc > ?HAS_APPIMAGE: noblacklist ${PATH}/nc > > Then the test AppImage also fails to run. As per man firejail the conditional '?HAS_APPIMAGE:' only works when it encounters '--appimage' as argument to the firejail command. At least as far as I can see in your responses throughout this issue that argument hasn't been used, which would explain it not doing anything positive in this context. In fact, using the '--appimage' on CLI (or it's counterpart 'appimage' in a profile file) is the recommended use of firejail with AppImages. That being said, I **can reproduce**, so marking this as a bug. Strangely enough `firejail --noprofile` works (without making any changes to the default profiles) while `firejail --noprofile --appimage` does not. To me that suggests something is broken in the implementation of that parameter (in https://github.com/netblue30/firejail/blob/1ad2d54c014a49f6ad0b487dd0d9b361cb4d299e/src/firejail/sandbox.c).

gitea-mirror commented

2026-05-05 08:42:50 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 28, 2020):

noblacklist must come before the blacklist.

?HAS_APPIMAGE: noblacklist ${PATH}/fusermount
blacklist ${PATH}/fusermount
?HAS_APPIMAGE: noblacklist ${PATH}/nc
blacklist ${PATH}/nc

@rusty-snake commented on GitHub (Feb 28, 2020): `noblacklist` **must** come before the `blacklist`. ``` ?HAS_APPIMAGE: noblacklist ${PATH}/fusermount blacklist ${PATH}/fusermount ?HAS_APPIMAGE: noblacklist ${PATH}/nc blacklist ${PATH}/nc ```

gitea-mirror commented

2026-05-05 08:42:50 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 28, 2020):

@bdantas As an workaround to get an default-appimage.profile.

/etc/firejail/default.local:

?HAS_APPIMAGE: include default-appimage.profile

/etc/firejail/default-appimage.profile:

ignore caps.drop all
ignore nonewprivs
ignore noroot
ignore protocol
ignore seccomp

@rusty-snake commented on GitHub (Feb 28, 2020): @bdantas As an workaround to get an default-appimage.profile. `/etc/firejail/default.local`: ``` ?HAS_APPIMAGE: include default-appimage.profile ``` `/etc/firejail/default-appimage.profile`: ``` ignore caps.drop all ignore nonewprivs ignore noroot ignore protocol ignore seccomp ```

gitea-mirror commented

2026-05-05 08:42:50 -06:00

Author

Owner

@ghost commented on GitHub (Feb 28, 2020):

Although, as (very) temporary workaround, the contribution of @rusty-snake is technically sound and valid - besides being well intended I'm sure - it is crucial to again remind AppImage users to what @Vincent43 already stated above: crippling firejail in such a way is an excersise in futility. Personally I've always wondered why firejail supports them in the first place and feel tempted to argue for dropping support, like we did for snap and flatpak. Just my 2 cents.

@ghost commented on GitHub (Feb 28, 2020): Although, as (very) temporary workaround, the contribution of @rusty-snake is technically sound and valid - besides being well intended I'm sure - it is crucial to again remind AppImage users to what @Vincent43 already stated above: crippling firejail in such a way is an excersise in futility. Personally I've always wondered why firejail supports them in the first place and feel tempted to argue for dropping support, like we did for snap and flatpak. Just my 2 cents.

gitea-mirror commented

2026-05-05 08:42:51 -06:00

Author

Owner

@Vincent43 commented on GitHub (Feb 28, 2020):

I understand what you're saying, but that's not what I was suggesting. I was suggesting a generic profile that allows what all AppImages need in order to mount the squashfs payload via fuse--let's call it the generic "AppImage loading" phase (all AppImages need to be allowed to call fusermount, for example).

Appimages historically worked with firejail --appimage option in most cases just fine. Did something changed recently in appimage runtime? I can reproduce issues with your example but on the other hand this one gui app created month ago work for me with default profile.

@Vincent43 commented on GitHub (Feb 28, 2020): > I understand what you're saying, but that's not what I was suggesting. I was suggesting a generic profile that allows what all AppImages need in order to mount the squashfs payload via fuse--let's call it the generic "AppImage loading" phase (all AppImages need to be allowed to call fusermount, for example). Appimages historically worked with `firejail --appimage` option in most cases just fine. Did something changed recently in appimage runtime? I can reproduce issues with your example but on the other hand [this one gui app](https://developers.yubico.com/yubioath-desktop/Releases/yubioath-desktop-5.0.2-linux.AppImage) created month ago work for me with default profile.

gitea-mirror commented

2026-05-05 08:42:51 -06:00

Author

Owner

@Vincent43 commented on GitHub (Feb 28, 2020):

That's a separate problem that perhaps could be solved by documentation in appimagehub that lets users of a specific AppImage know what additional (if any) application-specific privileges are needed beyond what's in the generic AppImage profile.

After commenting out proposed options in generic Appimage profile there would be no need to add any new privs because all of them would be already allowed for every appimage. Just some binaries and configs will be blacklisted and pid namespace would be used but any app would be able to escalate to full root access if it use some working 0day.

Even with current default profile appimages sandboxing is inferior in comparison with generic apps that use whitelisting but if it's true that current appimage runtime is incompatible with core firejail sandbox features then still calling appimages sandboxed will only get false sense security for users. I agree with comment above that in such case official appimage support should be dropped.

@Vincent43 commented on GitHub (Feb 28, 2020): > That's a separate problem that perhaps could be solved by documentation in appimagehub that lets users of a specific AppImage know what additional (if any) application-specific privileges are needed beyond what's in the generic AppImage profile. After commenting out proposed options in generic Appimage profile there would be no need to add any new privs because all of them would be already allowed for every appimage. Just some binaries and configs will be blacklisted and pid namespace would be used but any app would be able to escalate to full root access if it use some working 0day. Even with current default profile appimages sandboxing is inferior in comparison with generic apps that use whitelisting but if it's true that current appimage runtime is incompatible with core firejail sandbox features then still calling appimages sandboxed will only get false sense security for users. I agree with comment above that in such case official appimage support should be dropped.

gitea-mirror commented

2026-05-05 08:42:52 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

@Vincent43 I tested the AppImage (yubioath-desktop) in the link you provided. Like all the other AppImages I've tried or created myself, it only works in firejail if I use --noprofile or if I cripple default.profile as shown in my previous posts.

I sandboxed some additional applications (non-AppImages) in Tiny Core Linux and it turns out that anytime disable-common.inc is sourced by a profile, the application doesn't work unless I comment-out the line that blacklists nc. So the nc issue is a general firejail issue in Tiny Core Linux and is not specific to AppImages.

Please let the AppImage developers weigh in (especially @probonopd) before you guys make any decisions about official AppImage support in firejail. I'm just a user and know nothing about the internals of AppImage's runtime binary. Perhaps decreasing privilege requirements of the runtime would not be difficult. If that turns out to be the case, the only special consideration the AppImage loading phase would need from firejail is for fusermount to be allowed (via --appimage argument and the special ?HAS_APPIMAGE line in disable-common.inc).

@bdantas commented on GitHub (Feb 28, 2020): @Vincent43 I tested the AppImage (yubioath-desktop) in the link you provided. Like all the other AppImages I've tried or created myself, it only works in firejail if I use --noprofile or if I cripple default.profile as shown in my previous posts. I sandboxed some additional applications (non-AppImages) in Tiny Core Linux and it turns out that anytime disable-common.inc is sourced by a profile, the application doesn't work unless I comment-out the line that blacklists nc. So **the nc issue is a general firejail issue in Tiny Core Linux** and is not specific to AppImages. Please let the AppImage developers weigh in (especially @probonopd) before you guys make any decisions about official AppImage support in firejail. I'm just a user and know nothing about the internals of AppImage's runtime binary. Perhaps decreasing privilege requirements of the runtime would not be difficult. If that turns out to be the case, the only special consideration the AppImage loading phase would need from firejail is for fusermount to be allowed (via --appimage argument and the special ?HAS_APPIMAGE line in disable-common.inc).

gitea-mirror commented

2026-05-05 08:42:52 -06:00

Author

Owner

@Vincent43 commented on GitHub (Feb 28, 2020):

So we need to figure out if this is appimage issue, Tiny Core Linux issue or some specific issue to the way you create appimages. On my system I don't even have nc installed.

@Vincent43 commented on GitHub (Feb 28, 2020): So we need to figure out if this is appimage issue, Tiny Core Linux issue or some specific issue to the way you create appimages. On my system I don't even have `nc` installed.

gitea-mirror commented

2026-05-05 08:42:52 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 28, 2020):

I think the solution for the issue around nc is that @bdantas needs to pass enable-busybox-workaround to the configure script before compiling.

@smitsohu commented on GitHub (Feb 28, 2020): I think the solution for the issue around `nc` is that @bdantas needs to pass `enable-busybox-workaround` to the configure script before compiling.

gitea-mirror commented

2026-05-05 08:42:53 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

I think the first order of business is for me to move all testing to a more traditional distro. I have Devuan on a separate partition on my personal machine--it is a more traditional distro than TCL and uses GNU coreutils rather than BusyBox. I'm going to compile firejail 0.9.62 in Devuan right now.

I'm highly motivated to get to the bottom of this.

@bdantas commented on GitHub (Feb 28, 2020): I think the first order of business is for me to move all testing to a more traditional distro. I have Devuan on a separate partition on my personal machine--it is a more traditional distro than TCL and uses GNU coreutils rather than BusyBox. I'm going to compile firejail 0.9.62 in Devuan right now. I'm highly motivated to get to the bottom of this.

gitea-mirror commented

2026-05-05 08:42:53 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

Ok, I'm ready to roll:

$ cat /etc/os-release 
PRETTY_NAME="Devuan GNU/Linux ascii"
NAME="Devuan GNU/Linux"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

$ uname -a
Linux thinkpad 4.16.2-gnu #1 SMP Thu Apr 12 13:27:37 UTC 2018 x86_64 GNU/Linux

$ firejail --version
firejail version 0.9.62

Compile time support:
	- AppArmor support is disabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

I will do a few tests and will report back.

@bdantas commented on GitHub (Feb 28, 2020): Ok, I'm ready to roll: ``` $ cat /etc/os-release PRETTY_NAME="Devuan GNU/Linux ascii" NAME="Devuan GNU/Linux" ID=devuan ID_LIKE=debian HOME_URL="https://www.devuan.org/" SUPPORT_URL="https://devuan.org/os/community" BUG_REPORT_URL="https://bugs.devuan.org/" $ uname -a Linux thinkpad 4.16.2-gnu #1 SMP Thu Apr 12 13:27:37 UTC 2018 x86_64 GNU/Linux $ firejail --version firejail version 0.9.62 Compile time support: - AppArmor support is disabled - AppImage support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - firetunnel support is enabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled ``` I will do a few tests and will report back.

gitea-mirror commented

2026-05-05 08:42:54 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

@Vincent43 now I think we are on the same page.

I made no changes whatsoever to the files in /usr/local/etc/firejail.

Here are my results:

$ firejail ./yubioath-desktop-5.0.2-linux.AppImage # doesn't work
$ firejail --appimage ./yubioath-desktop-5.0.2-linux.AppImage # works
$ firejail --noprofile ./yubioath-desktop-5.0.2-linux.AppImage # works

$ firejail ./Dummy-x86_64.AppImage # doesn't work
$ firejail --appimage ./Dummy-x86_64.AppImage # doesn't work
$ firejail --noprofile ./Dummy-x86_64.AppImage # works

$ firejail ./Firefox-x86_64-20200118153954.AppImage # doesn't work
$ firejail --appimage ./Firefox-x86_64-20200118153954.AppImage # doesn't work
$ firejail --noprofile ./Firefox-x86_64-20200118153954.AppImage # works

So it seems Dummy and Firefox have the same issue, which does not affect yubioath. The Firefox AppImage is the 72.0.1 version available here: https://www.appimagehub.com/p/1331794/

@bdantas commented on GitHub (Feb 28, 2020): @Vincent43 now I think we are on the same page. I made no changes whatsoever to the files in /usr/local/etc/firejail. Here are my results: ``` $ firejail ./yubioath-desktop-5.0.2-linux.AppImage # doesn't work $ firejail --appimage ./yubioath-desktop-5.0.2-linux.AppImage # works $ firejail --noprofile ./yubioath-desktop-5.0.2-linux.AppImage # works $ firejail ./Dummy-x86_64.AppImage # doesn't work $ firejail --appimage ./Dummy-x86_64.AppImage # doesn't work $ firejail --noprofile ./Dummy-x86_64.AppImage # works $ firejail ./Firefox-x86_64-20200118153954.AppImage # doesn't work $ firejail --appimage ./Firefox-x86_64-20200118153954.AppImage # doesn't work $ firejail --noprofile ./Firefox-x86_64-20200118153954.AppImage # works ``` So it seems Dummy and Firefox have the same issue, which does not affect yubioath. The Firefox AppImage is the 72.0.1 version available here: https://www.appimagehub.com/p/1331794/

gitea-mirror commented

2026-05-05 08:42:54 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

It seems the issue with Dummy and Firefox has to do with permissions to run bash or AppRun:

$ firejail --appimage ./Firefox-x86_64-20200118153954.AppImage 
Mounting appimage type 2
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/default.profile
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-common.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-passwdmgr.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 18842, child pid 18845

**     Warning: dropping all Linux capabilities     **

Child process initialized in 86.21 ms
/bin/bash: /run/firejail/appimage/.appimage-18842/AppRun: Permission denied

Parent is shutting down, bye...
AppImage unmounted

$ firejail --appimage ./Dummy-x86_64.AppImage Mounting appimage type 2
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/default.profile
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-common.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-passwdmgr.inc
Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 18900, child pid 18903

**     Warning: dropping all Linux capabilities     **

Child process initialized in 116.30 ms
/bin/bash: /run/firejail/appimage/.appimage-18900/AppRun: Permission denied

Parent is shutting down, bye...
AppImage unmounted

@bdantas commented on GitHub (Feb 28, 2020): It seems the issue with Dummy and Firefox has to do with permissions to run bash or AppRun: ``` $ firejail --appimage ./Firefox-x86_64-20200118153954.AppImage Mounting appimage type 2 Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/default.profile Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-common.inc Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-passwdmgr.inc Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 18842, child pid 18845 ** Warning: dropping all Linux capabilities ** Child process initialized in 86.21 ms /bin/bash: /run/firejail/appimage/.appimage-18842/AppRun: Permission denied Parent is shutting down, bye... AppImage unmounted $ firejail --appimage ./Dummy-x86_64.AppImage Mounting appimage type 2 Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/default.profile Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-common.inc Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-passwdmgr.inc Reading profile /usr/local/stow/firejail-0.9.62/etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 18900, child pid 18903 ** Warning: dropping all Linux capabilities ** Child process initialized in 116.30 ms /bin/bash: /run/firejail/appimage/.appimage-18900/AppRun: Permission denied Parent is shutting down, bye... AppImage unmounted ```

gitea-mirror commented

2026-05-05 08:42:54 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 28, 2020):

https://github.com/netblue30/firejail/issues/2690#issuecomment-500023512

@rusty-snake commented on GitHub (Feb 28, 2020): https://github.com/netblue30/firejail/issues/2690#issuecomment-500023512

gitea-mirror commented

2026-05-05 08:42:55 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

Thanks, @rusty-snake. So I tried changing AppRun ownership to root:root and permissions to 755, no luck. Also tried 775, no luck.

EDIT: Ooooh, I see. The permisisons issue is on the /run/firejail/appimage/.appimage-XXXX/ directory, not on the AppRun binary. Gosh, how do I get the right permissions? I don't see an obvious solution in that thread.

@bdantas commented on GitHub (Feb 28, 2020): Thanks, @rusty-snake. So I tried changing AppRun ownership to root:root and permissions to 755, no luck. Also tried 775, no luck. EDIT: Ooooh, I see. The permisisons issue is on the /run/firejail/appimage/.appimage-XXXX/ directory, not on the AppRun binary. Gosh, how do I get the right permissions? I don't see an obvious solution in that thread.

gitea-mirror commented

2026-05-05 08:42:55 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 28, 2020):

dc12ce6a06/src/firejail/appimage.c (L98-L123)

@rusty-snake commented on GitHub (Feb 28, 2020): https://github.com/netblue30/firejail/blob/dc12ce6a06ba72d7b576864d2c981b00894e872b/src/firejail/appimage.c#L98-L123

gitea-mirror commented

2026-05-05 08:42:56 -06:00

Author

Owner

@bdantas commented on GitHub (Feb 28, 2020):

@rusty-snake pardon my ignorance, but I don't understand. Is this part of firejail's source code the problem or the solution? If the solution, are you saying I should use latest git instead of 0.9.62?

At any rate, it seems that I've beaten this to death. There turned out to be multiple pseudo-issues and just one real issue that's already known. Sorry for the noise.

@bdantas commented on GitHub (Feb 28, 2020): @rusty-snake pardon my ignorance, but I don't understand. Is this part of firejail's source code the problem or the solution? If the solution, are you saying I should use latest git instead of 0.9.62? At any rate, it seems that I've beaten this to death. There turned out to be multiple pseudo-issues and just one real issue that's already known. Sorry for the noise.

gitea-mirror commented

2026-05-05 08:42:56 -06:00

Author

Owner

@probonopd commented on GitHub (Mar 7, 2020):

What if you change dc12ce6a06/src/firejail/appimage.c (L102) from 0700 to 0755?

@probonopd commented on GitHub (Mar 7, 2020): What if you change https://github.com/netblue30/firejail/blob/dc12ce6a06ba72d7b576864d2c981b00894e872b/src/firejail/appimage.c#L102 from `0700` to `0755`?

gitea-mirror commented

2026-05-05 08:42:56 -06:00

Author

Owner

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

Nothing ☹️

@rusty-snake commented on GitHub (Mar 7, 2020): Nothing :frowning_face:

Rows
Columns

[GH-ISSUE #3249] settings in default.profile and disable-common.inc that break AppImages #2038